Kentucky Seeks Health Information Exchange System Services

PROPOSAL SUBMISSION CHECKLIST The vendor MUST include the following with the proposal submission.

If the items highlighted below are not submitted with the proposal submission, the Commonwealth MUST deem the proposal non-responsive and

SHALL NOT consider for award.

All other items MUST be submitted prior to award. FACE OF SOLICITATION - SIGNED [see Section 60.4] LATEST ADDENDUM - SIGNED [see Section 60.4] *PROPOSED TECHNICAL SOLUTION UNDER SEALED COVER AND BY CLOSING DATE AND TIME [see Sections 60.5 – 60.7] *PROPOSED COST SOLUTION UNDER SEALED COVER AND BY CLOSING DATE AND TIME [see Section 60.8 & Attachment B] TRANSMITTAL LETTER [see Section 60.6(A)] REVENUE FORM 10A100 KENTUCKY TAX REGISTRATION APPLICATION (see Section 60.6 (C)] CERTIFICATE OF AUTHORITY- REGISTRATION WITH SECRETARY OF STATE BY A FOREIGN ENTITY [see Section 60.6 (D)] REQUIRED AFFIDAVIT(S) [see Attachment C] EEO FORMS IF APPLICABLE [see Section 40.21]

*The Commonwealth defines SEALED as “a closure that must be broken to be opened and that thus reveals tampering”. (Merriam-Webster Dictionary, http://www.merriam-webster.com/dictionary/seal)

*Please see Attachment E - The Protection of Personal Information Security and

Breach Investigation Procedures and Practice Act (KRS 61.931), et seq. effective January 1, 2015.

ATTACHMENT A

Commonwealth of Kentucky Request for Proposal (RFP)

For KENTUCKY HEALTH INFORMATION EXCHANGE SYSTEM (KHIE)

RFP 758 1700000069

Release Date: September 7, 2016 CLOSING DATE AND TIME: October 21, 2016 at 3:30pm EST

(See Section 10.9 of this RFP for the Estimated Schedule of RFP Activities)

Issued by

The Finance and Administration Cabinet On Behalf Of

Cabinet for Health and Family Services (CHFS)

Commonwealth Buyer: Susan S. Noland

COMMONWEALTH OF KENTUCKY FINANCE AND ADMINISTRATION CABINET

Office of Procurement Services New Capitol Annex

702 CAPITOL AVE RM 096 FRANKFORT KY 40601

(502) 564-5951 Fax: (502) 564-6013

[email protected] TABLE OF CONTENTS Proposal Submission Checklist Section 10 – Introduction and Overview Section 20 – Background and Present System Summary Section 30 – Commonwealth Office of Technology Requirements Section 40 – Procurement Requirements Section 50 – Scope of Work Section 60 – Proposal Submission Section 70 – Proposal Evaluation Section 80 – Negotiations Section 90 – Attachments

SECTION 10 – INTRODUCTION AND OVERVIEW

10.1 Purpose The purpose of this Request for Proposal (RFP) is to solicit proposals for competitive negotiations pursuant to 200 KAR 5:307. The Cabinet for Health and Family Services (CHFS) is seeking vendors to provide the Kentucky Health Information Exchange (KHIE) System which provides statewide health information exchange services. The vendor shall propose a Service or SaaS solution to be hosted by the Vendor.

10.2 Issuing Office The Commonwealth of Kentucky, Finance and Administration Cabinet, Office of Procurement Services, is issuing this RFP on behalf of the Cabinet for Health and Family Services. The Finance and Administration Cabinet is the only office authorized to change, modify, amend, alter, or clarify the specifications, terms and conditions of this RFP.

A contract, based on this RFP, may or may not be awarded. Any contract award from this RFP is invalid until properly approved and executed by the Finance and Administration Cabinet.

10.3 Access to Solicitation, RFP, and Addenda The Commonwealth wants each prospective vendor to have full and complete information on which to base a proposal response. Only information presented or referred to in this RFP and any additional written information that is supplied by the Commonwealth Buyer shall be used by vendors in preparing the response.

The solicitation, addenda, and attachments shall be posted to the Kentucky Vendor Self Service site at https://emars.ky.gov/webapp/vssonline/AltSelfService. It is not necessary to register to access the solicitation. Unregistered vendors can access solicitations by clicking on public access.

In the event of any conflict or variation between the solicitation or modification as issued by the Commonwealth and the vendor’s response, the version as issued shall prevail.

10.4 RFP Terminology For the purpose of this RFP, the following terms may be used interchangeably:

o Proposer, Offeror, Contractor, Provider, or Vendor o Commonwealth Buyer, Buyer, Purchaser, or Contract Officer o RFP, Solicitation, or Procurement o Bid, Proposal, or Offer o Commonwealth of Kentucky, Commonwealth, or State, Agency, Cabinet

for Health and Family Services, CHFS

o Fiscal Year will be defined as the Commonwealth fiscal year: July 1 through June 30

o Biennium will be defined as the Commonwealth biennium: July 1 of each even numbered year through June 30 of the next even numbered year

o Requirements that include the words “Shall”, “Will”, “Must” indicate a mandatory requirement

10.5 Restrictions on Communications

The Commonwealth Buyer named on the Cover Sheet of this RFP shall be the sole point of contact throughout the procurement process. All communications, oral and written (regular, express, or electronic mail, or fax), concerning this procurement shall be addressed to the Buyer.

For violation of this provision, the Commonwealth shall reserve the right to disqualify the vendors’ proposal response.

10.6 Written Questions Regarding this RFP

Vendors are encouraged to submit written questions pursuant to Section 10.9 of this RFP. Written questions shall be submitted to the Commonwealth Buyer via email at [email protected] or via fax at 502-564-6013. Vendors should submit questions on Attachment D-Vendors Question Form. No questions shall be accepted after the date(s) listed in Section 10.9 unless the question(s) is considered material to the procurement. The Commonwealth shall respond to salient questions in writing by issuing an addendum to the solicitation. The addendum shall be posted to the Kentucky Vendor Self Service site.

10.7 Notification of Award of Contract

The procurement process will provide for the evaluation of proposals and selection of the successful proposal in accordance with State law and regulations. KRS Chapter 45A of the Kentucky Model Procurement Code provides the regulatory framework for the procurement of services by State agencies. All applicable statutes, regulations, policies and requirements shall become a part of an award as well as the Information Technology requirements.

To view the award of contract(s) and the contractor(s) receiving the award(s) for this solicitation, access the Kentucky Vendor Self Service site at https://emars.ky.gov/webapp/vssonline/AltSelfService. Vendors can search for the solicitation title or number in the keyword search field, or can filter their search for only awarded solicitations by clicking on Advanced Search and changing the status to “Awarded”. The award(s) information can be accessed by clicking on the details button of the solicitation and clicking the “Notice of Award” tab. It is the vendor’s responsibility to review this information in a timely fashion. No other notification of the results of an award of contract will be provided.

10.8 Protest

Pursuant to KRS 45A.285, the Secretary of the Finance and Administration Cabinet, or his designee, shall have authority to determine protests and other controversies of actual or prospective offerors in connection with the solicitations or selection for award of a contract. Any actual or prospective offeror or contractor, who is aggrieved in connection with solicitation or selection for award of a contract, may file protest with the Secretary of the Finance and Administration Cabinet. A protest or notice of other controversy must be filed promptly and in any event within two (2) calendar weeks after such aggrieved person knows or should have known of the facts giving rise thereto. All protests or notices of other controversies must be in writing and shall be addressed and mailed to:

William M. Landrum III, Secretary COMMONWEALTH OF KENTUCKY

FINANCE AND ADMINISTRATION CABINET New Capitol Annex

702 CAPITOL AVE RM 383 FRANKFORT KY 40601

The Secretary of Finance and Administration Cabinet shall promptly issue a decision in writing. A copy of that decision shall be mailed or otherwise furnished to the aggrieved party and shall state the reasons for the action taken. The decision by the Secretary of the Finance and Administration Cabinet shall be final and conclusive.

10.9 Estimated Schedule of RFP Activities The following table presents the anticipated schedule for major activities associated with the RFP distribution, proposal submission, proposal evaluation process, and contract award. The Commonwealth reserves the right at its sole discretion to change the Schedule of Activities, including the associated dates and time.

Anticipated Schedule of Activities

Release of RFP

September 7, 2016

Vendors’ Written Questions due by 10:00 AM EST (SUBMIT QUESTIONS ON ATTACHMENT D-VENDORS’ QUESTION FORM)

September 20, 2016

Commonwealth’s Response to Vendors’ Written Questions

September 27, 2016

Proposals due by 3:30 PM EST

October 21, 2016

All bidders are cautioned to be aware of security in the Capitol Annex in Frankfort. In-person or courier delivered bids/proposals in response to a Commonwealth solicitation should be delivered a minimum of thirty (30) minutes

to one (1) hour earlier than the published closing date and time to allow for a security check-in. Delays due to building security checks shall not be justification for acceptance of a late bid or proposal. Vendor attention to this advisory is encouraged.

SECTION 20 – BACKGROUND AND PRESENT SYSTEM SUMMARY 20.1 Background

The Kentucky Cabinet for Health and Family Services (CHFS) began development of the KHIE in 2009 with funds received from the Centers for Medicare and Medicaid Services to provide the technical infrastructure for statewide health information exchange (HIE). The vision was to support HIE through a shared HIE technology infrastructure for the Commonwealth that would enable access to health information across healthcare providers and to promote interoperability among disparate health systems. That vision took on added momentum with the passage of the American Recovery and Reinvestment Act (ARRA) of 2009, which provided a roadmap for transforming the nation’s health system through unprecedented investments in the development of a nationwide electronic information system, including state grants for HIE development and financial incentives to healthcare providers who demonstrate meaningful use of health information exchange. The first pilot hospital was connected to the original function of KHIE in April 2010, while statewide rollout began in January 2011. The pilot participants were seven (7) hospitals including large healthcare organizations of all geographic regions of the Commonwealth. That original functionality continues to see expansion and use across the Commonwealth today.

Today KHIE provides a baseline set of exchange functions in a secure electronic information infrastructure. It continues in the direction of being designed and built according to national standards to ensure interoperability across disparate health records systems and connectivity to the e-Health Exchange (formerly the National Health Information Network or NHIN). In 2015 the Office of the National Coordinator (ONC) publicized its Ten Year Interoperable Health IT Infrastructure Roadmap and KHIE supports this direction. The system gives healthcare providers additional functionality to support preventive health and disease management efforts through alerts, messaging, and other tools. As criteria for determining meaningful use are established, functionality will be added to support providers in achieving meaningful use.

Current and future functional requirements are included in this RFP and attachments. The goal of enabling health information exchange in Kentucky is not just about providing the technology, but is also about providing a high level of patient-centered care. KHIE is not intended to supplant the doctor-patient relationship, but to reduce the administrative burden of a paper records system, thereby enhancing the doctor-patient relationship by freeing the provider to spend more time with the patient. KHIE’s open systems-based health information exchange infrastructure will allow State health-related programs and the Commonwealth’s healthcare providers to share information about common

recipients and to empower providers through the use of electronic clinical support tools.

Kentucky Health Information Exchange Readiness By 2014, 82 percent of Kentucky’s acute care hospitals had reported that they electronically exchanged health information with outside ambulatory providers or other hospitals. This was higher than the national average, but only 49 percent reported that they had exchanged clinical care summaries. With the help of KHIE these numbers have continued to grow. There are 135 different known Electronic Medical Record (EMR) products being used in Kentucky from 113 software vendors. 122 of the 135 are 2014 ONC-Authorized Testing and Certification Body Certified (ATCB), 65 are interoperable with KHIE today and five (5) more are in testing, ten (10) are only 2011 ONC-ATCB Certified. Three (3) of the 135 are not ONC-ATCB certified at all. KHIE and KY CHILD have signed an agreement to develop an interface that will help automate the collection of human services data pertaining to the birth of a newborn and mapping of disparate identifiers. KY CHILD is a web based application that allows for electronic collection and submission of data related to Certificate of Live Birth, Certificate of Still Birth, newborn metabolic and hearing screenings required at birth and provides the daily data feed for Kentucky’s statewide Immunization Registry. The application is used statewide by 1,900 staff in all Kentucky birthing facilities as well as several programmatic areas within CHFS. The system was developed by the CHFS Office of Administrative and Technology Services (OATS) in cooperation and consultation with the Kentucky Department of Public Health (DPH), Vital Statistics. These solutions improves data quality in KHIE and the KY Immunization Registry, and reduces, if not eliminates, errors in newborn information. Kentucky recently passed an Electronic Laboratory Reporting (ELR) regulation that mandates all providers send reportable diseases electronically via KHIE. The regulation is effective October 1, 2016. Please click here http://www.lrc.ky.gov/kar/902/002/020.htm to learn more about the regulation. On Dec. 16, 2014, the Cabinet received a $2 million State Innovation Model (SIM) design grant from the Center for Medicare and Medicaid Innovation (CMMI) of CMS.

20.2 Present System Background KHIE presently supports numerous forms of HIE including Directed Exchange and Query-Based Exchange as defined by the ONC on www.healthit.gov. Using KHIE technology, participating providers can access, locate, and share needed patient health information with other providers at the point of care to facilitate better care coordination. KHIE is a statewide HIE that includes: a master patient index, two data repositories with one containing a longitudinal health record, a record locator service, security, provider/user authentication, logging, and audits. The system includes patient demographics, lab results, radiology and other transcribed reports, historical patient diagnoses, encounters, and procedures. KHIE acts as data intermediary for public health reporting to the state immunization and cancer registries, reporting of syndromic surveillance data and reportable labs/diseases. A valuable aspect of the information that is available to providers is the Medicaid claims data formatted as clinical information. KHIE receives a nightly deposit of

Medicaid claims data, ultimately enriching the HIE experience and constructing a more robust HIE for the Commonwealth. In addition to the Medicaid claims data, KHIE plans to connect to the Commonwealth’s All Payer Claims Database in a similar way. KHIE has 750 separate signed participating business organizations representing approximately 3,000 facilities or doorways. There are 1,100 facilities live or actively testing with a total of nearly 2,800 data feeds live or being tested. Table 1 lists the current connection types with description, Table 2 shows data feeds accepted by connection type, Table 3 shows the counts by data feed and connection type and Table 4 shows the number of provider locations signed to work with KHIE by provider group. Many organizations have multiple feeds and some of those may be only logical where two feeds of a similar type exist. For example Syndromic Surveillance can share a feed with an ADT feed with logic differences.

Data Feed Description ADT Admit, Discharge, and Transfer messages provide basic patient

demographics. Required for Lab, Rad, Transcription, Syndromic Surveillance and Electronically Reportable Labs feeds. Accepts HL7 ADT transaction codes A01, A03, A04, and A08.

Syndromic Surveillance - Public Health Feed

Builds on top of the ADT feed to submit diagnosis and syndromic monitoring data to Biosense 2.0.

Lab Results Provides KHIE with lab tests and results originated from the provider as ORU^R01 HL7 messages.

Electronic Laboratory Reporting (ELR) - Public Health Feed

Sends qualifying results from a Lab Results feed on to the Kentucky Department of Public Health, as required in Title 902 of KAR, as ORU^R01 HL7 messages.

Transcription Accepts transcribed reports as ORU^R01 HL7 messages. Radiology Accepts medical imaging reports as ORU^R01 HL7 messages. Continuity of Care Document (CCD)

Standardized document that gives a summary of information on a patient. The CCD is contained within an MDM^T02 HL7 message.

Immunization Registry Public Health Feed

Sends record of administered immunizations on to the Kentucky Immunization Registry as VXU HL7 messages.

Cancer Registry - Public Health Feed

Send C32 CDA-type document to the Kentucky Cancer Registry.

XDS.b Cross-Enterprise Document Sharing

Provides KHIE XDS.b documents generated by the participant

XCA Cross-Community Architecture

Provide KHIE participants access to data located in a separate community by way of IHE XCA profile.

Direct Secure Messaging

Allow send and receive of secure messages to and from any other Direct account including all Direct Trusted Agent Accreditation Program accredited accounts.

Table 1- Data Feed Connection Type Descriptions

Data Feed

Accepted via Web Services

Accepted via VPN

Accepted via Direct

ADT X X Cancer Registry X CCD – Repose & Query X

CCD – Query only X Immunizations X X Labs X X ELR X X Pathology X Radiology X Syndromic Surveillance X X Transcription X XDS.b or XCA exchange X Secure Messaging X

Table 2 - Data Feed accepted by Connection Type

Web

Services VPN MLLP Total ADT 200 676 33 909 Cancer Registry 5 5 CCD - Repose and Query 13 138 CCD - Query only 21 21 Immunizations 953 753 38 1744 Labs 4 65 5 74 ELR 6 32 3 41 Pathology 5 5 Radiology 47 47 Syndromic Surveillance 132 555 32 719 Transcriptions 69 69 XDS.b or XCA 273 273 Grand Total 1607 2202 111 3920

Table 3 - Current Data Feed Connection Counts by Connection Type (Includes both live and testing connections)

Provider Points of Care grouped by Category

Signed with live feed

Signed with no live feed Total signed

Hospitals 94 21 115 Corrections 1 0 1 Dental 0 18 18 Vision 56 104 196 Behavioral Health & Community Mental Health Centers 5 229 234 Health Departments & LTC 0 771 771 Pharmacies 216 79 295 Cancer Centers 3 4 7 Chiropractor 1 11 12

Dermatology 4 20 24 Other Providers 951 1708 2659 TOTAL 1331 3001 4332

Table 4 – Signed Participating Provider Points of Care grouped by Category with one or more live feed versus no live feeds

Table 4 shows 9489 signed participating hospitals having one (1) or more live Web Service, VPN or MLLP data feeds. Those 94 hospitals have345 of the data feeds distributed in Table 3 live. The total number of provider points of care with a live feed is 1,331 and they have 2,613 of the data feeds from Table 3 live. The remaining data feeds in Table 3 are in test.

There are 2,000 web-based provider portal user accounts allowing access to the patient’s longitudinal health record and 401 web-based provider portal user accounts allowing access to Direct Secure Messaging. There are 21 connections to KHIE’s Health Information Service Provider (HISP) function which use the Cross Enterprise Reliable Interchange (XDR) protocol standard to route Direct Secure Messages for transitions of care and Meaningful Use efforts. In addition to the current system described above, KHIE and KY CHILD have signed an agreement to develop an interface that will automate mapping of disparate identifiers, improve data quality in KHIE and the KY Immunization Registry, and reduce, if not eliminate, errors in newborn information. Kentucky also recently passed an ELR regulation that mandates that all hospitals send specific reportable labs electronically via KHIE. Kentucky Health Information Exchange Usage The system presently receives 14 million Admit, Discharge, and Transfer (ADT) transactions per month, roughly 700,000 Virtual Health Record (VHR) queries per month, 2 million lab transactions per month, and 250,000 CCD queries per month. There are four (4) key areas to pay close attention to in reviewing the RFP and responding. First, there is a tremendous need for a better, more streamlined eMPI environment with mature functionality and management tools and some but not necessarily all corresponding requirements can be found in 50.7.1.8, 50.7.2.2 and 50.7.1.6. Second, there is a significant need for more sophisticated provider testing and onboarding processes with excellent tools and tracking that provides visibility into new and existing connections enabling a quick assessment of both new and ongoing connections. It is taking too long to get connections up and in place and awareness that a connection has an issue takes far too long to obtain. Some but not necessarily all of these requirements can be found in 50.7.1.4 and 60.5.9 l. Third the system must have a proven track record integrating claims information to be additional available information displayed along with the clinical. Some but not necessarily all of these requirements can be found in 50.7.1.1 A. and I as well as 50.7.2.8 K. and 50.7.2.13. Fourth the system must have proven, working implementations of both HL7 and Integrating the Healthcare Enterprise (IHE) exchange together using a single eMPI. Some but not necessarily all of the

HL7 requirements can be found in 50.7.2.5 and 50.7.2.8; some but not necessarily all of the IHE requirements can be found in 50.7.2.10; and some but not necessarily all of the single eMPI requirements can be found in 50.7.1.8 and 50.7.2.2. Kentucky is seeking an HIE vendor that will help build upon the past success by implementing a flexible, yet operationally efficient, system using clean and measurable processes. The selected vendor must serve as a long-term partner to help Kentucky establish a sustainable KHIE.

SECTION 30 – COMMONWEALTH OFFICE OF TECHNOLOGY (COT)

REQUIREMENTS

30.1 Commonwealth Information Technology Policies and Standards The vendor and any subcontractors shall be required to adhere to applicable Commonwealth policies and standards related to technology use and security.

30.2 Compliance with Kentucky Information Technology Standards (KITS)

A. The Kentucky Information Technology Standards (KITS) reflect a set of principles for information, technology, applications, and organization. These standards provide guidelines, policies, directional statements and sets of standards for information technology. It defines, for the Commonwealth, functional and information needs so that technology choices can be made based on business objectives and service delivery. The vendor shall stay knowledgeable and shall abide by these standards for all related work resulting from this RFP.

http://technology.ky.gov/Governance/Pages/KITS.aspx

B. The vendor and any subcontractors shall be required to submit a technology roadmap for any offered solution. Additional roadmaps will be submitted upon request of the Commonwealth. The Roadmap shall include, but is not limited to, planned, scheduled and projected product lifecycle dates and historical release/ patch or maintenance dates for the technology. In addition, any guidance on projected release/revision/patch/maintenance schedules would be preferred.

30.3 Compliance with Commonwealth Security Standards The software deployment and all vendor services shall abide by security standards as outlined in the Commonwealth’s Enterprise Information Technology Policies. Enterprise Security Policies http://technology.ky.gov/ciso/Pages/InformationSecurityPolicies,StandardsandProcedures.aspx

Enterprise Policies

http://technology.ky.gov/policy/pages/policies.aspx Finance and Administration Cabinet Commonwealth Office of Technology Enterprise IT Policies http://finance.ky.gov/services/policies/Pages/default.aspx

30.4 Compliance with Industry Accepted Reporting Standards Based on Security Controls and Trust Principles The vendor must employ a comprehensive risk and threat management approach based on defined industry standards for service organizations such as the Statement on Standards for Attestation Engagements (SSAE 16). The vendor must undergo annual controls reviews based on these standards and have the ability to demonstrate compliance through the applicable reporting mechanisms associated with these reviews. This shall include providing access to any publicly available reports (i.e. SSAE 16 SOC 3) as well as on site reviews of reports available specifically for business partners (i.e. SSAE 16 SOC 2).

30.5 System Vulnerability and Security Assessments The Commonwealth reserves the right to conduct external non-invasive vulnerability and security assessments of the software and infrastructure used to provide services prior to implementation and periodically thereafter. Upon completion of these assessments, the Commonwealth will communicate any findings to the vendor for action. Any cost relating to the alleviation of the findings will be the responsibility of the vendor. Mitigations will be subject to re-evaluation after completion. In cases where direct mitigation cannot be achieved, the vendor shall communicate this and work closely with the Commonwealth to identify acceptable compensating controls that will reduce risk to an acceptable and agreed upon level. An accredited third party source may be selected by the vendor to address findings, provided they will acknowledge all cost and provide valid documentation of mitigation strategies in an agreed upon timeframe.

30.6 Privacy, Confidentiality and Ownership of Information

The Commonwealth Office of Technology (COT) is the designated owner of all data and shall approve all access to that data. The vendor shall not have ownership of Commonwealth data at any time. The vendor shall be in compliance with privacy policies established by governmental agencies or by state or federal law. Privacy policy statements may be developed and amended from time to time by the Commonwealth and will be appropriately displayed on the Commonwealth portal (Ky.gov). The vendor should provide sufficient security to protect the Commonwealth and COT data in network transit, storage, and cache. All sensitive data, as defined in Enterprise Standards, must be encrypted in-transit.

30.7 Software Development

Source code for software developed or modified by the vendor specifically for the Commonwealth shall become property of the Commonwealth. This is not meant to include minor modifications to the vendor software to configure the software for Commonwealth use. This is meant to include software written to add functionality to the vendor product specifically to meet the requirements of the Commonwealth where the Commonwealth bears the entire cost of creating that functionality.

30.8 License Agreements

Software provided by the vendor to the Commonwealth should contain a provision for perpetual licensing with all upgrade options. License agreements should also contain a provision for the Commonwealth to maintain a version of the software in escrow in the event the vendor is unable to continue business for financial or other business reasons.

30.9 Software Version Requirements

All commercially supported and Commonwealth approved software components such as Operating system (OS), Database software, Application software, Web Server software, Middle Tier software, and other ancillary software must be kept current. In the event that a patch interferes with the solution, the vendor must present a plan for compliance to the Commonwealth outlining the constraints and an appropriate plan of action to bring the solution in to compliance to allow this patch to be applied in the shortest timeframe possible, not to exceed three months, unless otherwise negotiated with the Commonwealth. The vendors shall keep software in compliance with industry standards to support third party dependencies such as Java, Adobe Flash, Internet Explorer, Mozilla Firefox, etc. at currently supported version, release, and patch levels. In the event that a third party dependency interferes with the solution, the vendor must present a plan for compliance to the Commonwealth outlining the constraints and an appropriate plan of action to bring the solution into compliance to allow this third party dependency to be updated in the shortest timeframe possible, not to exceed three months, unless otherwise negotiated with the Commonwealth.

30.10 Section 508 Compliance

All user interfaces to the solution(s) provided, shall be warranted by the vendor to comply with Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. 794d) and the World Wide Web Consortium’s (W3C) Web Content Accessibility Guidelines (WCAG) 1.0, conformance level Double-A or greater.

30.11 No Surreptitious Code Warranty The contractor represents and warrants that no copy of licensed Software provided to the Commonwealth contains or will contain any Self-Help Code or any Unauthorized Code as defined below. This warranty is referred to in this contract as the "No Surreptitious Code Warranty”.

As used in this contract, "Self-Help Code" means any back door, time bomb, drop dead device, or other software routine designed to disable a computer program automatically with the passage of time or under the positive control of a person other than the licensee of the software. Self-Help Code does not include Software routines in a computer program, if any, designed to permit an owner of the computer program (or other person acting by authority of the owner) to obtain access to a licensee's computer system(s) (e.g. remote access) for purposes of maintenance or technical support. As used in this contract, "Unauthorized Code" means any virus, Trojan horse, spyware, worm or other Software routines or components designed to permit unauthorized access to disable, erase, or otherwise harm software, equipment, or data; or to perform any other such actions. The term Unauthorized Code does not include Self-Help Code. In addition, contractor will use up-to-date commercial virus detection software to detect and remove any viruses from any software prior to delivering it to the Commonwealth. The vendor shall defend the Commonwealth against any claim, and indemnify the Commonwealth against any loss or expense arising out of any breach of the No Surreptitious Code Warranty.

30.12 Applicable Security Control Framework Compliance The vendor must have an awareness and understanding of the NIST Special Publication 800-53 Security Control Framework and employ safeguards that meet or exceed the moderate level controls as defined within the standard. These controls must provide sufficient safeguards to provide reasonable protections around the Commonwealth’s data to ensure that the confidentiality, integrity, and availability is maintained at an appropriate level. These include but are not limited to: Access Control

The vendor must employ policy and process that provide for stringent control to limit physical and logical access to systems that house Commonwealth data to a need to know basis and provide clear separation of duties.

Awareness and Training The vendor must provide the appropriate role specific training for staff to ensure that there is awareness and understanding of roles and responsibilities as they relate to the protections around the Commonwealth’s data.

Audit and Accountability There must be sufficient auditing capability to ensure that actions are tracked and there is individual accountability for all actions taken by vendor staff.

Configuration Management The vendor must work within established baselines that provide minimal functionality needed to ensure service delivery without exposing unnecessary

risk. The vendor must also employ structured change control processes that provide a level of coordination with the client agreed upon in a Service Level Agreement (SLA).

Contingency Planning The vendor must employ contingent planning policy and procedures that ensure service delivery based on agreed SLA levels while maintaining all Commonwealth data within the continental Unites States.

Identification and Authorization The vendor must employ appropriate identity and access management policies and procedures to ensure that access is appropriately authorized and managed at a level to ensure that access is provisioned and de-provisioned in a timely and efficient manner.

Incident Response The vendor must employ policy and procedures to ensure that an appropriate response to all identified security incidents are addressed in a timely manner and are reported to the appropriate parties in an agreed upon SLA timeframe. The vendor must also ensure that all staff are sufficient trained to ensure that they can identify situations that are classified as security incidents.

Maintenance The vendor must employ policy and procedures that ensure that all maintenance activities are conducted only by authorized maintenance staff leveraging only authorized maintenance tools.

Media Protection The vendor must employ policy and procedure to ensure that sufficient protections exist to protect Commonwealth data on all storage media throughout the media lifecycle and maintain documentation from media creation through destruction.

Physical and Environmental Controls The vendor must employ physical and environmental policies and procedures that ensure that the service and delivery infrastructure are located in a physically secure and environmentally protected environment to ensure the confidentiality, integrity, and availability of Commonwealth data.

Personnel Security The vendor must employ policies and procedures to ensure that all staff that have access to systems that house, transmit, or process Commonwealth data have been appropriate vetted and have been through a background check at the time of hire and periodically thereafter.

System and Communications Protections The vendor must employ physical and logical protection that protect system communications and communication media from unauthorized access and to ensure adequate physical protections from damage.

SECTION 40 – PROCUREMENT REQUIREMENTS

40.1 Procurement Requirements Procurement requirements are listed under “Procurement Laws, Preference, Regulations and Policies” and “Response to Solicitation” located on the eProcurement Web page at http://eprocurement.ky.gov and http://finance.ky.gov/services/eprocurement/Pages/VendorServices.aspx respectively. The vendor must comply with all applicable statutes, regulations and policies related to this procurement.

40.2 Contract Components and Order of Precedence

The Commonwealth’s acceptance of the contractor’s offer in response to the solicitation, indicated by the issuance of a contract award by the Office of Procurement Services, shall create a valid contract between the Parties consisting of the following: 1. Any written Agreement between the Parties; 2. Any Addenda to the Solicitation; 3. The Solicitation and all attachments; 4. Procurement Statutes, Regulations and Policies; 5. Any Best and Final Offer; 6. Any clarifications concerning the Contractor’s proposal in response to the

Solicitation; 7. The Contractor’s proposal in response to the Solicitation.

In the event of any conflict between or among the provisions contained in the contract, the order of precedence shall be as enumerated above.

40.3 Final Agreement

The contract represents the entire agreement between the parties with respect to the subject matter hereof. Prior negotiations, representations, or agreements, either written or oral, between the parties hereto relating to the subject matter hereof shall be of no effect upon this contract.

40.4 Contract Provisions

If any provision of this contract (including items incorporated by reference) is declared or found to be illegal, unenforceable, or void, then both the Commonwealth and the contractor shall be relieved of all obligations arising under such provision. If the remainder of this contract is capable of performance, it shall not be affected by such declaration or finding and shall be fully performed.

40.5 Type of Contract

The contract proposed in response to this solicitation shall be on the basis of a firm fixed unit price for the elements listed in this solicitation. This solicitation is specifically not intended to solicit proposals for contracts on the basis of cost-plus, open-ended rate schedule, nor any non-fixed price arrangement.

40.6 Contract Usage As a result of this RFP, the contractual agreement with the selected vendor will in no way obligate the Commonwealth of Kentucky to purchase any services or

equipment under this contract. The Commonwealth agrees, in entering into any contract, to purchase only such services in such quantities as necessary to meet the actual requirements as determined by the Commonwealth.

40.7 Addition or Deletion of Items or Services

The Office of Procurement Services reserves the right to add new and similar items, by issuing a contract modification, to this contract with the consent of the vendor. Until such time as the vendor receives a modification, the vendor shall not accept delivery orders from any agency referencing such items or services.

40.8 Changes and Modifications to the Contract

Pursuant to KRS 45A.210 (1) and 200 KAR 5:311, no modification or change of any provision in the contract shall be made, or construed to have been made, unless such modification is mutually agreed to in writing by the contractor and the Commonwealth, and incorporated as a written amendment to the contract and processed through the Office of Procurement Services and approved by the Finance and Administration Cabinet prior to the effective date of such modification or change pursuant to KRS 45A.210(1) and 200 KAR 5:311. Memorandum of understanding, written clarification, and/or correspondence shall not be construed as amendments to the contract.

If the contractor finds at any time that existing conditions made modification of the contract necessary, it shall promptly report such matters to the Commonwealth Buyer for consideration and decision.

40.9 Changes in Scope

The Commonwealth may, at any time by written order, make changes within the general scope of the contract. No changes in scope are to be conducted except at the approval of the Commonwealth.

40.10 Contract Conformance If the Commonwealth Buyer determines that deliverables due under the contract are not in conformance with the terms and conditions of the contract and the mutually agreed-upon project plan, the Buyer may request the contractor to deliver assurances in the form of additional contractor resources and to demonstrate that other major schedules will not be affected. The Commonwealth shall determine the quantity and quality of such additional resources and failure to comply may constitute default by the contractor.

40.11 Assignment

The contract shall not be assigned in whole or in part without the prior written consent of the Commonwealth Buyer.

40.12 Payment

The Commonwealth will make payment within thirty (30) working days of receipt of contractor's invoice or of acceptance of goods and/or services in accordance with KRS 45.453 and KRS 45.454.

Payments are predicated upon successful completion and acceptance of the described work, services, supplies, or commodities, and delivery of the required documentation. Invoices for payment shall be submitted to the agency contact person or his representative.

40.12.1 Milestone Payments for Planning, Implementation and Go-Live A. Phase I – Planning Billing shall not exceed 35% of the total sum of Cost Category 1 Implementation Cost and Cost Category 2 Data Conversion and Provider Connection Migration. B. Phase II Implementation Billing shall not exceed 55% of the total sum of Cost Category 1 Implementation Cost and Cost Category 2 Data Conversion and Provider Connection Migration. C. Phase III Go Live – 10% of the total sum of Cost Category 1 Implementation Cost and Cost Category 2 Data Conversion and Provider Connection Migration will be retained until final acceptance post Go Live

40.12.2 Retainage/DDI Liquidated Damages The Commonwealth and the Contractor agree that the timely roll out of the KHIE in conformity with the Contract provisions is necessary to the proper operation of CHFS’s programs. Timely performance of KHIE DDI Milestones, Payments and Penalties shall be material to the purpose of this Contract.

The Commonwealth and the Contractor shall further agree that while failures to meet milestones identified under this Contract may or will affect the delivery of medical services either directly or indirectly and may or will result directly or proximately in monetary damages to the Commonwealth, the actual amount of such injury and damage might be impossible or extremely difficult to calculate. Therefore, the Commonwealth and the Contractor shall agree to a 10% overall DDI phase retainage and that the Commonwealth shall reduce compensation to the Contractor during the DDI phase in the instances and amounts hereinafter set forth in this Contract as determined by the Commonwealth. The Parties also agree that the stated reduction in compensation amounts is reasonable and not punitive. The KHIE Contract Administrator shall issue written notification to the Contractor of each failure to meet a milestone or agreed upon Service Level Agreement (SLA). The imposition and reduction in compensation shall not affect any other rights of the Commonwealth to enforce or terminate this Contract. If a single event results in the potential for multiple liquidated damages, the Commonwealth shall select only one damage remedy to apply for that event. The Commonwealth may exercise multiple remedies as provided in this Contract or by applicable law, provided that the Commonwealth shall not receive double recovery for financial damages. If the Commonwealth elects not to exercise a reduction in compensation clause in a particular instance, this decision shall not be construed as a waiver of the

Commonwealth’s right to pursue future assessment of required milestones that were not met and the associated reduction in compensation.

40.12.2.1 Phase I Legacy Replacement KHIE Operational Start Dates Performance Standard

The Contractor shall have the Phase I Legacy Replacement KHIE fully operational within six (6) months of contract execution. Phase I Legacy Replacement KHIE shall consist of all KHIE functional requirements listed in the RFP other than the following possible Phase II KHIE functional requirements. Only the specific items identified by its alphabetic letter as a sub component as well as the entire requirement designated with “All” can be delayed to Phase II. All other items not identified remain requirements of Phase I. 50.7.1.6 – A9, A10 only 50.7.1.8 – F only 50.7.2.6 – G, J, K, L, M, N, O, P, Q, R, S, U, W, X only 50.7.2.7 – B, M, P, S only. 50.7.2.8 – L, M only 50.7.2.9 – E only 50.7.2.10 – D, H only 50.7.2.11 – All 50.7.2.12 – A, D, F and G only All KHIE functional requirements must be completed in Phase I or Phase II.

40.12.2.2 Phase II Enhanced KHIE Operational Start Dates Performance Standard

The Contractor shall have the Phase II Enhanced Replacement KHIE fully operational within one year of contract execution. Those requirements which may be part of Phase II are identified in 1.1.

Phase I and Phase II Start Date Damages

Compliance with the Phase I Legacy Replacement KHIE within six (6) months of contract execution and Phase II New KHIE within one year of contract execution KHIE operational start dates is critical to the Commonwealth’s interest. If the Contractor does not fully meet the operational start dates approved in the KHIE DDI Phase Detailed Project Work Plan, then the Contractor shall be liable for all costs incurred by the Commonwealth to continue the Legacy KHIE and Contractor operations. The Contractor shall also forfeit all claims for payment of monthly expenses and operational payments for that month and each month thereafter until the Commonwealth approves operational readiness.

40.12.2.3 System Certification Performance Standard The Contractor shall ensure that Federal certification approval for the maximum allowable enhanced Federal Financial Participation (FFP) for the KHIE is

achieved within one (1) year of the contractual operational start date and that FFP is retroactively approved to the contractual operational start date. In addition, the Contractor shall ensure that that Federal certification approval for the maximum allowable enhanced FFP for the KHIE is maintained throughout the life of the Contract. Shall certification fail to be achieved within one (1) year of the contractual KHIE operations start date, the Contractor shall be liable for any damages resulting from its actions or inactions relating to the lack of certification. Shall certification fail to be approved retroactively to the contractual KHIE operational start date, the Contractor shall be liable for any damages resulting from its actions or inactions relating to the loss of maximum allowable enhanced FFP. Shall de-certification of the KHIE or any component part of either, occur prior to the end of the Contract period, the Contractor shall be liable for any damages resulting from its actions or inactions relating to the de-certification and loss of maximum allowable enhanced FFP. System Certification Damages For any violation of the Contract, the Contractor shall be liable for the Commonwealth and Federal dollar difference between the maximum allowable enhanced FFP and that actually received by the Commonwealth, including any losses due to lack of or loss of certification. All FFP penalty claims assessed by CMS or other Federal agencies shall be withheld from monies payable to the Contractor until all such penalty claims have been satisfied.

40.12.2.4 DDI Milestones

The documentation to be delivered during the DDI and Warranty phase and payment schedule shall be concurrent with the milestone schedule and the payment schedule. Payment shall not be issued for a milestone until all products associated with the Milestone have been approved in their final state by the Commonwealth. The Commonwealth shall consider a deliverable document or other product to be delivered in optimal condition if: (a.) The indicators of quality and completeness are met. (b.) The Contractor satisfactorily addresses all comments and concerns of the

Commonwealth, documented in its review of the initial submission of the product, in the first re-submission.

During the warranty period, the Contractor shall deliver a monthly maintenance report which shall include an application/operations performance report card.

The Commonwealth shall consider a monthly maintenance report to be delivered in optimal condition if: (a.) The monthly maintenance report meets the quality and completeness. (b.) The performance report card shows that all of the performance standards

in the performance report card have been met.

40.12.2.5 DDI Milestone Dates Performance Standards The Contractor is required to design, develop, test, and implement Phase I Legacy Replacement KHIE within six (6) months of contract execution and Phase II New KHIE within one year of contract execution. Accomplishment of certain specified KHIE DDI Phase activities by the key milestone dates, as defined and established in the approved KHIE DDI Phase Detailed Work Plan, shall be necessary to ensure full compliance with the start date.

If, for any reason, the Contractor is delayed in meeting these key milestone dates and a Contract modification to the KHIE DDI Phase Detailed Work Plan is not approved, a reduction in compensation may be assessed. Approval of a Contract or KHIE DDI Phase Detailed Work Plan modification does not waive the Commonwealth's ability to impose damages and/or reductions in compensation if warranted by other terms of the Contract.

The reductions in compensation listed in Subsection F. shall be in addition to any amounts assessed for delays in meeting the operational start date.

DDI Milestone Dates Reduction in Compensation The Commonwealth may reduce compensation up to one thousand dollars ($1,000.00) per calendar day, or any part thereof, for each of the first ten (10) calendar days of delay in meeting a milestone date.

The Commonwealth may reduce compensation up to two thousand dollars ($2,000.00) per calendar day, or any part thereof, for each of the next twenty (20) calendar days of delay in meeting a milestone date.

The Commonwealth may reduce compensation up to three thousand dollars ($3,000.00) per calendar day, or any part thereof, for each additional calendar day of delay in meeting a milestone after thirty (30) calendar days.

40.12.2.6 DDI Deliverable Due Dates Performance Standards

Copies of each deliverable, as defined in the approved KHIE DDI Phase Detailed Work Plan, shall be delivered to the CHFS, in final form, in the number specified and on the date specified in the approved KHIE DDI Phase Detailed Work Plan. CFHS may require one (1) up to ten (10) paper copies and one (1) electronic copy of all deliverables. The electronic copy shall be compatible with Microsoft Word or other application software as requested by the CHFS, and submitted on the Commonwealth-specified media. All deliverables shall be in a format approved by the CHFS, and meet content and accuracy requirements specified or as subsequently defined by the CHFS and agreed to by Contractor.

DDI Deliverable Due Dates Reduction in Compensation The Commonwealth may assess five hundred dollars ($500.00) for each calendar day, or any part thereof, that a deliverable is late, which includes providing less than the required copies or delivery on incorrect media.

The Commonwealth may assess an additional five hundred dollars ($500.00) for each calendar day, or any part thereof, that a deliverable continues to not meet minimum content requirements or the approved format after its formal rejection by CHFS, when appropriate.

40.12.2.7 Contract End Turnover Milestone Dates Performance Standards

The Contractor shall be required to provide full support for system turnover activities in accordance with the CHFS approved Contractor Turnover Plan as follows:

a) Assistance in turning over the complete and most current KHIE to the

Commonwealth or its agent. b) Assistance and support in turnover activities necessary to affect an orderly,

structured, smooth turnover to enable the CHFS and the new Contractor achieve successful transition of system operations to a new KHIE system operated by the Commonwealth or its agent.

Accomplishment of certain specified turnover activities by key milestone dates, as established in the Commonwealth-approved KHIE Turnover Plan, shall be necessary to ensure full compliance with the start date.

If, for any reason, the Contractor is delayed in meeting these key milestone dates and a Contract Modification to the KHIE Turnover Plan is not approved, a reduction in compensation may be assessed. Approval of a Contract or KHIE Turnover Plan modification does not waive the Commonwealth's ability to impose damages and/or reductions in compensation if warranted by other terms of the Contract. The reductions in compensation below shall be in addition to any amounts assessed for delays in meeting the operational start date.

Contract End Turnover Milestone Dates Damages

The Commonwealth may reduce compensation up to one thousand dollars ($1,000.00) per calendar day, or any part thereof, for each of the first ten (10) calendar days of delay in meeting a milestone date.

The Commonwealth may reduce compensation up to two thousand dollars ($2,000.00) per calendar day, or any part thereof, each of the next twenty (20) calendar days of delay in meeting a milestone date.

The Commonwealth may reduce compensation up to three thousand dollars ($3,000.00) per calendar day, or any part thereof, for each additional calendar day of delay in meeting a milestone after thirty (30) days.

40.12.2.8 Contract End Turnover Deliverable Due Dates Performance Standards

Copies of each deliverable, as defined in the Contract, shall be delivered to CHFS, when appropriate, in final form, in the number specified and on the date specified in the approved KHIE Turnover Plan. CHFS, when appropriate, may

require one (1) up to ten (10) paper copies and one (1) electronic copy of all deliverables. The electronic copy shall be compatible with Microsoft Word or other application software as requested by CHFS, when appropriate, and submitted on the Commonwealth-specified media. All deliverables shall be in a format approved by CHFS, when appropriate, and meet content and accuracy requirements specified or as subsequently defined by CHFS, when appropriate.

Contract End Turnover Deliverable Due Dates Damages

The Commonwealth may assess up to five hundred dollars ($500.00) for each calendar day, or any part thereof, that a deliverable is late which includes providing less than the required copies or delivery on incorrect media. The Commonwealth may assess up to an additional five hundred dollars ($500.00) for each calendar day or any part thereof that a deliverable continues to not meet minimum content requirements or the approved format after its formal rejection by CHFS, when appropriate.

40.12.2.9Key and Lead Personnel Performance Standard

The Contractor and the Commonwealth will work together to development the staffing requirements for the DDI portion of the project. The Contractor must make every effort to keep Key and Lead Personnel throughout the DDI period of the contract.

Key and Lead Personnel Reduction in Compensation

The Commonwealth may assess up to ten thousand dollars ($10,000.00) in reduction in compensation for each key or lead personnel who is changed for reasons other than death, disability, resignation, termination, or military recall. The Commonwealth may assess up to an additional one thousand dollars ($1,000.00) in reduction in compensation per Commonwealth business day after the initial twenty-five (25) Commonwealth business days allowed for Contractor to find an acceptable replacement for the key and lead personnel and an acceptable replacement has not provided. If the contractor fails to maintain ninety percent (90%) of the mutually agreed to staffing plan for a period exceeding thirty (30) contiguous calendar days, the Commonwealth may assess up to an additional one thousand dollars ($1,000.00) in reduction in compensation per Commonwealth business day after the initial thirty (30) Commonwealth business days allowed for Contractor to find an acceptable replacements to maintain the ninety percent (90%) staffing level.

40.12.2.10 Monthly DDI Performance Report Card Performance Standards A sample Monthly DDI Requirements Status Report Card detailing the requirements and performance that will be required is contained at the end of this section. Within fifteen (15) calendar days of the end of each month during DDI,

the Contractor shall be required to produce and deliver a report card on its actual performance as detailed herein. There are two (2) sections to the Report Card. The first section addresses all Contract requirements identified in this Contract. The second section addresses any and all performance standards offered in the Contractor's proposal. Due to the changing environment, report card Contract requirements/performance standards and Vendor Supplied Measurements shall be reevaluated annually for appropriateness and any addition to the report card shall be finalized through joint negotiation between the Commonwealth and the Contractor.

Sample Monthly DDI Requirements Status Report Card

Monthly DDI Requirements Status Report Card DDI Section 1 – Contract Requirements Met: 0 out of 10

Requirement # Requirement Description Status* 1.1 Phase I Legacy Replacement KHIE Operational Start Date 1.2 Phase II Enhanced KHIE Operational Start Date 1.3 System Certification 1.4 DDI Milestones 1.5 DDI Deliverable Due Dates 1.6 Contract End Key Turnover Phase Milestone Dates 1.7 Contract End Turnover Phase Deliverable Due Dates 1.8 Key Personnel 1.9 Training

1.10 Monthly DDI Performance Report Card

DDI Section 2 – Contract Functional Requirements Met: 0 out of 119 2.1 Registration 2.2 Testing 2.3 Security 2.4 Security Logging and Audit 2.5 Documentation 2.6 Infrastructure 2.7 Performance Reliability 2.8 Public Health Reporting 2.9 IHE

2.10 Query Based Exchange 2.11 Directed Exchange 2.12 Event Notification 2.13 HIE Monitoring and Reporting

DDI Section 3 – Vendor Supplied Measurements Met: xx out of xx

Requirement # Requirement Description Status* 3.1 Sample

* Status should be either Met, Not Met, or NA when Not Applicable when appropriate

40.12.3 Forfeiture of Retainage In the event of the Contractor’s failure to meet the ongoing operational performance standard requirements prior to payment of DDI retainage, the Contractor agrees that the Commonwealth may retain and withhold payment of a percentage of the original retainage amount as set forth below until they have all been met for three consecutive months: a) The failure to meet one (1) performance standard requirement = forfeiture

of five percent (5%) of the retainage amount. b) The failure to meet two (2) performance standard requirements = forfeiture

of ten percent (10%) of the retainage amount. c) The failure to meet three (3) performance standard requirements =

forfeiture of fifty percent (50%) of the retainage amount. d) The failure to meet four (4) performance standard requirements =

forfeiture of seventy-five percent (75%) of the retainage amount. e) The failure to meet five (5) or more performance standard requirements =

forfeiture of one hundred percent (100%) of the retainage amount.

40.12.3.1 Delay or Interruption of Operations Performance Standard

The Contractor shall ensure there shall be no delays or interruptions in the operation of the proposed KHIE solution and related services caused by any failure, act, or omission of the Contractor. “Delay” means service is not restored from normal, acceptable outages at the agreed upon date and time.

40.12.3.2 Delay or Interruption of Operations Damages

Delays or interruptions in the operation of the KHIE and related services caused by any failure, act, or omission of the Contractor beyond the SLA shall constitute a material breach. Regardless if the Commonwealth elects to terminate this Contract upon such a breach, it is nevertheless entitled to recover: a) The difference between the cost to the Commonwealth under this Contract

and the cost to it under any interim or substitute contract or other method of operation.

b) The liability of the Commonwealth to any third person arising directly or consequentially out of the Contractor’s breach and cancellation of this Contract.

c) The cost to the Commonwealth of all actions taken by it to locate and secure a substitute or interim Contractor or method of operation.

d) The loss of FFP.

In addition to the above, the Commonwealth shall reduce the Contractor’s compensation by the following amounts: a) Up to one thousand dollars ($1,000) per calendar day, or any part thereof, for

each of the first ten (10) calendar days of delay or interruption of operation continues.

b) Up to two thousand dollars ($2,000) per calendar day, or any part thereof, for each of the next twenty (20) calendar days of delay or interruption of operation continues.

c) Up to three thousand dollars ($3,000) per calendar day, or any part thereof, for each additional calendar day of delay or interruption of operation continues after thirty (30) days.

40.12.3.3 Operational Documentation Performance Standard

The Contractor shall be responsible for providing the Commonwealth with complete, accurate, and timely documentation of all modifications made to the operational KHIE. Such documentation shall be in accordance with specifications approved by the CHFS. Any changes that occur to the operational system shall be documented according to specifications approved by the CHFS. Documentation of any such changes shall be provided to the CHFS.

Operational Documentation Reduction in Compensation

Beyond the SLA the Commonwealth may reduce compensation up to five hundred dollars ($500.00) for each business day, or any part thereof (beginning

the next business day after the documentation due date) that the required documentation has not been provided to the Commonwealth.

The Commonwealth may reduce compensation up to five hundred dollars ($500.00) for each business day, or any part thereof, during which the documentation is unacceptable as to format, accuracy, and completeness based on the CHFS review. Reduction in compensation may be imposed until the Contractor provides the Commonwealth with acceptable documentation.

40.12.3.4 Online Access to KHIE Availability and Response Time Performance Standard

Beyond the SLA the Contractor shall provide the Commonwealth staff with online access to all KHIE online screens, systems, and data, including all Web-enabled capabilities, 24x7x365 except for Commonwealth approved maintenance timeframes. Response time average shall be less than or equal to three (3) seconds for Commonwealth access to inquiry and update screens and no more than eleven (11) seconds.

Online Access to KHIE Availability and Response Time Reduction in Compensation

Beyond the SLA the Commonwealth may reduce compensation up to one thousand dollars ($1,000.00) for every rounded percentage point below the SLA for each month in which Commonwealth does not have online access available. The Commonwealth may reduce compensation up to five hundred dollars ($500.00) per calendar day for each day having a KHIE inquiry or update screen that has a documented average response time greater than three (3) seconds or maximum greater than eleven (11) seconds.

40.12.3.5 KHIE Query Availability and Response Time Performance Standards

The Contractor shall ensure KHIE Query functionality is available 24x7x365, except for Commonwealth-approved maintenance timeframes. The Contractor shall provide a response for query in thirty (30) seconds or less, ninety-nine percent (99%) of the time.

KHIE Query Availability and Response Time Reduction in Compensation

Beyond the SLA the Commonwealth shall reduce compensation by up to one thousand dollars ($1,000.00) per hour when the KHIE Query or a component of Query is not available for provider response for greater than one (1) hour in a calendar day, other than scheduled or Commonwealth-approved down time. The Commonwealth may reduce compensation up to five hundred dollars ($500.00) for every percentage point below the SLA for each month in which the response time for query does not meet response time as required within the Contract.

40.12.3.6 KHIE HISP Availability and Response Time Performance Standards

The Contractor shall ensure KHIE HISP functionality is available 24x7x365, except for Commonwealth-approved maintenance timeframes. The Contractor shall provide a response for query in thirty (30) seconds or less, ninety-nine percent (99%) of the time.

KHIE Query Availability and Response Time Reduction in Compensation

Beyond the SLA the Commonwealth shall reduce compensation by up to one thousand dollars ($1,000.00) per hour when the KHIE HISP functionality is not available for provider response for greater than one (1) hour in a calendar day, other than scheduled or Commonwealth-approved down time. The Commonwealth may reduce compensation up to five hundred dollars ($500.00) for every percentage point below ninety-nine percent (99%) for each month in which the response time for HISP functionality does not meet response time as required within the Contract.

40.12.3.7 Connection Onboarding Stats Up to Date with Monthly Reporting Performance Standards

The Contractor shall keep the Connection Onboarding statistics up-to-date and in order to provide monthly reporting. The Contractor must log all agreed upon onboarding information real-time. Any information which is contained in the reports and not the responsibility of the Contractor will not reflect upon the Contractor.

Connection Onboarding Stats Up to Date with Monthly Reporting Reduction in Compensation

Beyond the SLA the Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

40.12.3.8 Call Center Support and Staffing Performance Standards The Contractor shall add and maintain a sufficient number of telephone lines and staff so at least ninety percent (90%) of incoming calls, routed from the KHIE, per day are answered within one (1) minute inclusive of “hold” time. A caller shall not be placed on "hold", ring busy, or go unanswered for more than thirty (30) seconds.

Call Center Support and Staffing Reduction in Compensation

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each 10% of calls not meeting the 1 minute SLA. (80-89.9 % = $100.00, 70-79.9% = $200.00, etc.).

40.12.3.9 Call Center Reporting Performance Standards The Contractor shall provide agreed upon monthly reporting on call center activity.

Call Center Reporting Reduction in Compensation

Beyond the Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

40.12.3.10 Provider Directory Maintenance and Reporting Performance Standard The Contractor shall provide update capabilities and import\export the directory routinely. If self-service is not available to update, import or export then the Contractor must provide that service and include the performance of those steps in the routine reporting data. Provider Directory Maintenance and Reporting Reduction in Compensation

Beyond the SLA the Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

40.12.3.11 Single eMPI Maintenance and Reporting Performance Standard The Contractor shall provide the capability to match patient and business demographic records having variable data based on configurable rules, register identities with the CHFS master MDM, handle alias, baby names, and pseudo-entries, and effectively delete or mark bad identities. It should also allow for automated cleanup routines. eMPI Reporting should utilize stats which track these and other related eMPI functions and provide visibility of that activity. Single eMPI Maintenance and Reporting Reduction in Compensation

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

40.12.3.12 Event Notification Statistics Reporting Performance Standard The Contractor shall provide reporting on the activity and usage of the Event Notification System. This includes but is not limited to the number of rules, number of patient lists, number of unique patients, and number of events sent to subscribers. Event Notification Statistics Reporting Reduction in Compensation

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

40.12.3.13 Active Users Reporting Performance Standard The Contractor shall deliver a final report entitled “Active Users” within five (5) business days of the end of each month. Active Users Reporting Reduction in Compensation

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

40.12.3.14 Meaningful Use Reporting Performance Standard The Contractor shall deliver agreed upon Meaningful Use reporting during the entire term of the contract or until the Meaningful Use program final dates reporting would produce.

Meaningful Use Reporting Reduction in Compensation

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

40.12.3.15 Daily Transaction Activity Reporting Performance Standard The Contractor shall deliver agreed upon reporting which shows transactions at maximum granularity of daily to be summarized to weekly, monthly, etc. and by data feed or by connection type.

Daily Transaction Activity Reporting Reduction in Compensation

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

40.12.3.16 Daily Claims Imported Reporting Performance Standard The Contractor shall deliver agreed upon claims imported transaction reporting which shows transactions at maximum granularity of daily to be summarized to weekly, monthly, etc. Daily Claims Imported Reporting Reduction in Compensation

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

40.12.3.17 Security Activity Reporting Performance Standard The Contractor shall deliver agreed upon monthly reporting which provides KHIE security activity information such as the number of locked accounts due to exceeding invalid attempts. Security Activity Reporting Reduction in Compensation

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

40.12.3.18 Key and Lead Personnel Performance Standard The Contractor and the Commonwealth will work together to development the staffing requirements for the ongoing operations of the project. The Contractor must make every effort to keep Key and Lead Personnel throughout the live of the contract.

Key and Lead Personnel Reduction in Compensation

Beyond the SLA the Commonwealth may assess up to ten thousand dollars ($10,000.00) in reduction in compensation for each key or lead personnel who is

changed for reasons other than death, disability, resignation, termination, or military recall. The Commonwealth may assess up to an additional one thousand dollars ($1,000.00) in reduction in compensation per Commonwealth business day after the initial twenty-five (25) Commonwealth business days allowed for Contractor to find an acceptable replacement for the key and lead personnel and an acceptable replacement has not provided. If the contractor fails to maintain ninety percent (90%) of the mutually agreed to staffing plan for a period exceeding thirty (30) contiguous calendar days, the Commonwealth may assess up to an additional one thousand dollars ($1,000.00) in reduction in compensation per Commonwealth business day after the initial thirty (30) Commonwealth business days allowed for Contractor to find an acceptable replacements to maintain the ninety percent (90%) staffing level.

40.12.3.19 Ongoing Training Requirements Performance Standard The Contractor and the Commonwealth must address all ongoing training requirements based on an approved CHFS training program for all KHIE, subsystems, functional components (systems and operations), interfaces, procedures, and confidentiality. Ongoing Training Requirements Reduction in Compensation

Beyond the SLA the Commonwealth may reduce compensation up to five hundred dollars ($500.00) for each ongoing training requirement not held within 30 days of the agreed upon training plan.

40.12.3.20 Monthly Operations Performance Report Card A sample Monthly Operations Report Card detailing the requirements and performance that will be required is contained in this section. Within fifteen (15) calendar days of the end of each month of Operations, the Contractor shall be required to produce and deliver a report card on its actual performance as detailed herein. There are two (2) sections to the Report Card. The first section addresses all Contract requirements identified in this Contract. The second section addresses any and all performance standards offered in the Contractor's proposal. Thirty (30) days prior to each year, the Commonwealth will identify twenty-five (25) requirements/performance standards and shall use these standards to review the Contractor’s actual performance. All items within Report Card shall be measurable. The Report Cards shall be generated by the Contractor in a means that is the most efficient and accurate in order to deliver metrics to the Commonwealth as required in this Contract. The Commonwealth, or its designee(s), shall reserve the right to audit records and data related to the Contractor’s performance at any time during the Contract period.

Due to the changing environment, report card Contract requirements/performance standards shall be reevaluated annually for appropriateness and any addition to the report card shall be finalized through joint negotiation between the Commonwealth and the Contractor. Sample Monthly Operations Performance Report Card

Monthly Operations Performance Report Card

Operations Section 1 – Contract Requirements Met: 0 out of 19 Requirement # Requirement Description Status*

1.1 Delay or Interruption of Operations 1.2 Documentation of All Ongoing Modifications According to Specifications 1.3 Online Access to KHIE Availability and Response Time 1.4 KHIE Query Availability and Response Time 1.5 KHIE HISP Services Availability and Response Time 1.6 Connection Onboarding Stats Up to Date 1.7 Call Center Support and Staffing 1.8 Call Center Reporting 1.9 Provider Directory Maintenance and Reporting

1.10 Single eMPI Operational 1.11 Event Notification Stats Up to Date 1.12 Active Users Reporting 1.13 Meaningful Use Reporting 1.14 Daily Transaction Activity Reporting 1.15 Daily Claims Imported Reporting 1.16 Security Activity Reporting 1.17 Key Personnel 1.18 Ongoing Training Requirements 1.19 Monthly Operations Performance Report Card

Operations Section 2 – Vendor Supplied Measurements Met: xx out of xx

Requirement # Requirement Description Status* 2.1 Sample

The failure to meet 1 performance standard requirement = forfeiture of 5% of the original retainage amount; The failure to meet 2 performance standard requirements = forfeiture of 10% of the original retainage amount; The failure to meet 3 performance standard requirements = forfeiture of 50% of the original retainage amount; The failure to meet 4 performance standard requirements = forfeiture of 75% of the original retainage amount; and/or The failure to meet 5 or more performance standard requirements = forfeiture of 100% of the original retainage amount. The original retainage amount is the 10% retained amount used during the DDI portion. * Status should be either Met, Not Met, or NA for Not Applicable when appropriate

34

Monthly Operation Performance Report Card Details

Operations Section 1 – Contract Requirements

Report Card

Report Card Performance Requirement Reductions/Damages Measurement

Criteria & SLA Status

1.1 No Delay or Interruption of Operations requires the Contractor to ensure there will be no delays or interruptions in the operation of the KHIE and related services caused by any failure, act, or omission of the Contractor. “Delay” means service is not restored from normal, acceptable outages at the agreed upon date and time.

Delays or interruptions in the operation of the KHIE and related services caused by any failure, act, or omission of the Contractor beyond the SLA shall constitute a material breach. The Commonwealth is entitled to recover: (a) The difference between the cost to the Commonwealth under this Contract and the cost to it under any interim or substitute contract or other method of operation; (b)The liability of the Commonwealth to any third person arising directly or consequentially out of the Contractor’s breach and cancellation of this Contract; (c) The cost to the Commonwealth of all actions taken by it to locate and secure a substitute or interim Contractor or method of operation; and (d) The loss of FFP. In addition to the above, the Commonwealth shall reduce the Contractor’s compensation by the following amounts: (1) Up to one thousand dollars ($1,000.00) per calendar day, or any part thereof, for each of the first ten (10) calendar days of delay or interruption of operation continues; (2) Up to two thousand dollars ($2,000.00) per calendar day, or any part thereof, for each of the next twenty (20) calendar days of delay or interruption of operation continues; and (3) Up to three thousand dollars ($3,000.00) per calendar day, or any part thereof, for each additional calendar day of delay or interruption of operation continues after thirty (30) days.

Hours of delay or service interruption\total expected hours of availability. SLA is 98%

35

Report Card

Report Card Performance Requirement Reductions/Damages Measurement

Criteria & SLA Status

1.2 Documentation of All Ongoing Modifications According to Specifications requires the Contractor to be responsible for providing the Commonwealth with complete, accurate, and timely documentation of all modifications made to the operational KHIE. Such documentation shall be in accordance with specifications approved by the CHFS. Any changes that occur to the operational system shall be documented according to specifications approved by the CHFS.

Beyond the SLA the Commonwealth may reduce compensation up to five hundred dollars ($500.00) for each business day, or any part thereof (beginning the next business day after the documentation due date) that the required documentation has not been provided to the Commonwealth. The Commonwealth may reduce compensation up to five hundred dollars ($500.00) for each business day, or any part thereof, during which the documentation is unacceptable as to format, accuracy, and completeness based on the CHFS review. Reduction in compensation may be imposed until the Contractor provides the Commonwealth with acceptable documentation.

Documentation provided\documentation expected SLA is 100%

1.3 Online Access to KHIE Availability and Response Time requires the Contractor to provide the Commonwealth staff and users online access to all KHIE online screens, systems, and data, including all Web-enabled capabilities, 24x7x365 except for Commonwealth approved maintenance timeframes. Response time average shall be less than or equal to three (3) seconds for Commonwealth access to inquiry and update screens and no more than eleven (11) seconds.

Beyond the SLA the Commonwealth may reduce compensation up to one thousand dollars ($1,000.00) for every rounded percentage point below the SLA for each month in which Commonwealth does not have online access available. The Commonwealth may reduce compensation up to five hundred dollars ($500.00) per calendar day for each day having a KHIE inquiry or update screen that has a documented average response time greater than three (3) seconds or maximum greater than eleven (11) seconds.

Hours of actual availability\total expected hours of availability for the period of measure. SLA is 99% Response time: repeatable and recorded response times. SLA for response time is 3 second average, 11 second maximum.

1.4 KHIE Query Availability and Response Time requires the Contractor to ensure KHIE Query functionality is available 24x7x365, except for Commonwealth-approved maintenance timeframes. The Contractor shall provide a response for each query in thirty (30) seconds or less, ninety-nine percent (99%) of the time.

Beyond the SLA the Commonwealth shall reduce compensation by up to one thousand dollars ($1,000.00) per hour when the KHIE Query or a component of Query is not available for provider response for greater than one (1) hour in a calendar day, other than scheduled or Commonwealth-approved down time. The Commonwealth may reduce compensation up to five hundred dollars ($500.00) for every percentage point below the SLA for each month in which the response time for query does not meet response time as required within the Contract.

Hours KHIE Query functionality not available\total expected hours of availability. SLA is 99% Response time: repeatable and recorded response times. SLA is 30 seconds or less 99% of the time.

36

Report Card

Report Card Performance Requirement Reductions/Damages Measurement

Criteria & SLA Status

1.5 KHIE HISP Services Availability and Response Time requires the Contractor to ensure KHIE HISP functionality is available 24x7x365, except for Commonwealth-approved maintenance timeframes. The Contractor shall provide a response for query in thirty (30) seconds or less, ninety-nine percent (99%) of the time.

Beyond the SLA the Commonwealth shall reduce compensation by up to one thousand dollars ($1,000.00) per hour when the KHIE HISP functionality is not available for provider response for greater than one (1) hour in a calendar day, other than scheduled or Commonwealth-approved down time. The Commonwealth may reduce compensation up to five hundred dollars ($500.00) for every percentage point below ninety-nine percent (99%) for each month in which the response time for HISP functionality does not meet response time as required within the Contract.

Hours KHIE HISP functionality not available\total expected hours of availability. SLA is 99% Response time: repeatable and recorded response times. SLA is 30 seconds or less 99% of the time.

1.6 Connection Onboarding Stats Up to Date with Monthly Reporting requires the Contractor to keep the Connection Onboarding statistics up-to-date and in order to provide monthly reporting. The Contractor must log all agreed upon onboarding information real-time. Any information which is contained in the reports and not the responsibility of the Contractor will not reflect upon the Contractor.

Beyond the SLA the Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

SLA is Real-time information must be logged with a 24 hour period and monthly reports are due five business days after the end of each month.

1.7 Call Center Support and Staffing requires the Contractor to add and maintain a sufficient number of telephone lines and staff so at least ninety percent (90%) of incoming calls, routed from the KHIE, per day are answered within one (1) minute inclusive of “hold” time. First time resolution rate should not be lower than 33%.

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each 10% of calls not meeting the 1 minute SLA. (80-89.9 % = $100.00, 70-79.9% = $200.00, etc.)

SLA is 90% of calls received are answered within 1 minute and a first time resolution rate of 33% or greater.

1.8 Call Center Reporting requires the Contractor to provide agreed upon monthly reporting on call center activity.

Beyond the SLA the Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

SLA is 95% or more reports delivered five business days after the end of each month.

37

Report Card

Report Card Performance Requirement Reductions/Damages Measurement

Criteria & SLA Status

1.9 Provider Directory Maintenance and Reporting requires the Contractor to provide update capabilities and import\export the directory routinely. If self-service is not available to update, import or export then the Contractor must provide that service and include the performance of those steps in the routine reporting data.

Beyond the SLA the Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

SLA is 95% or more reports delivered five business days after the end of each month.

1.10 Single eMPI Maintenance and Reporting requires the capability to match patient and business demographic records having variable data based on configurable rules, register identities with the CHFS master MDM, handle alias, baby names, and pseudo-entries, and effectively delete or mark bad identities. It should also allow for automated cleanup routines. eMPI Reporting should utilize stats which track these and other related eMPI functions and provide visibility of that activity.

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

SLA is 95% or more reports delivered five business days after the end of each month.

1.11 Event Notification Statistics Reporting requires the Contractor to provide reporting on the activity and usage of the Event Notification System. This includes but is not limited to the number of rules, number of patient lists, number of unique patients, and number of events sent to subscribers.

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

SLA is 95% or more reports delivered five business days after the end of each month.

1.12 Active Users Reporting requires the Contractor to deliver a final report entitled “Active Users” within five (5) business days of the end of each month.

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

SLA is 95% or more reports delivered five business days after the end of each month.

1.13 Meaningful Use Reporting requires the Contractor to deliver agreed upon Meaningful Use reporting during the entire term of the contract or until the Meaningful Use program final dates reporting would produce.

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

SLA is 95% or more reports delivered five business days after the end of each month.

38

Report Card

Report Card Performance Requirement Reductions/Damages Measurement

Criteria & SLA Status

1.14 Daily Transaction Activity Reporting requires the Contractor to deliver agreed upon reporting which shows transactions at maximum granularity of daily to be summarized to weekly, monthly, etc. and by data feed or by connection type.

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

SLA is 95% or more reports delivered five business days after the end of each month.

1.15 Daily Claims Imported Reporting requires the Contractor to deliver agreed upon claims imported transaction reporting which shows transactions at maximum granularity of daily to be summarized to weekly, monthly, etc.

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

SLA is 95% or more reports delivered five business days after the end of each month

1.16 Security Activity Reporting requires the Contractor to deliver agreed upon monthly reporting which provides KHIE security activity information such as the number of locked accounts due to exceeding invalid attempts.

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

SLA is 95% or more reports delivered five business days after the end of each month

1.17 Key personnel commitments contained in the Contractor's proposal for all phases of the contract shall not be changed without prior written approval of the KHIE Contract Administrator, unless due to the death, disability, resignation, termination, or military recall or of any named individual. Staffing includes the staff proposed for all key positions required within this RFP at the levels of effort proposed or as specified in the Contract.

Anything less than 95% and the Commonwealth may assess up to ten thousand dollars ($10,000.00) in reduction in compensation for each key personnel proposed in the Contractor’s response to the RFP who is changed for reasons other than death, disability, resignation, termination, or military recall. The Commonwealth may assess up to an additional one thousand dollars ($1,000.00) in reduction in compensation per Commonwealth business day after the initial twenty-five (25) Commonwealth business days allowed for Contractor to find an acceptable replacement for the key personnel and an acceptable replacement has not provided.

Contractor staff retained during the course of project/Total Contractor staff assigned to the project in approved KHIE Staff Plan. SLA is 95% or higher.

1.18 Ongoing Training Requirements must address all ongoing training requirements based on an approved CHFS training program for all KHIE, subsystems, functional components (systems and operations), interfaces, procedures, and confidentiality

Beyond the SLA the Commonwealth may reduce compensation up to five hundred dollars ($500.00) for each ongoing training requirement not held within 30 days of the agreed upon training plan.

Training provided\training agreed and expected per training plan SLA is 95%

39

Report Card

Report Card Performance Requirement Reductions/Damages Measurement

Criteria & SLA Status

1.19 Monthly Operations Performance Report Card - Within fifteen (15) calendar days of the end of each month, the Contractor shall be required to produce and deliver a report card on its actual performance as detailed herein. There are two (2) sections to the Report Card. The first section addresses all Contract requirements identified in this Contract. The second section addresses any and all performance standards offered in the Contractor's proposal. Due to the changing environment, report card performance standard contract requirements and Vendor Supplied Measurements shall be reevaluated annually for appropriateness and any addition to the report card shall be finalized through joint negotiation between the Commonwealth and the Contractor.

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

SLA is minimum of 95% of the reports delivered ten business days after the end of each month.

40

Operations Section 2 – Vendor Supplied Measurements Report Card #

Response Reference Report Card Performance Requirement Performance This Month Status

2.1 Sample 2.2

2.3 2.4 2.5 2.6 2.7 2.8 2.9

2.10

Sample Monthly DDI Requirements Status Report Card

DDI Section 1 – Contract Requirements

Report Card

Report Card Performance Requirement Reductions/Damages Measurement

Criteria & SLAs Status

1.1 Phase I Legacy Replacement KHIE Operational Start Date requires that the Contractor shall have the Phase I Legacy Replacement KHIE fully operational within six (6) months of contract execution.

If the Contractor does not fully meet the operational start date approved in the Finalized Work Plan, then the Contractor shall be liable for all costs incurred by the Commonwealth to continue the Legacy KHIE and Contractor operations. The Contractor shall also forfeit all claims for payment of monthly expenses and operational payments for that month and each month thereafter until the Commonwealth approves KHIE Phase I operational readiness.

Phase I Legacy Replacement KHIE contractual operational start date is within six (6) months of contract execution

1.2 Phase II Enhanced KHIE Operational Start Date requires that the Contractor shall have the Phase II Enhanced KHIE fully operational within one year of contract execution.

The Contractor shall forfeit all claims for payment of monthly expenses and operational payments for that month and each month thereafter until the Commonwealth approves operational readiness.

Phase II Legacy Enhanced KHIE contractual operational start date is within one year of contract execution.

41

Report Card

Report Card Performance Requirement Reductions/Damages Measurement

Criteria & SLAs Status

1.3 System Certification requires that the Contractor shall ensure that Federal certification approval for the maximum allowable enhanced Federal Financial Participation (FFP) for the New KHIE is achieved within one (1) year of the Phase I Legacy Replacement KHIE contractual operational start date and that FFP is retroactively approved to the contractual operational start date. In addition, the Contractor shall ensure that that Federal certification approval for the maximum allowable enhanced FFP for the New KHIE and/or New KHIE is maintained throughout the life of the Contract. Should certification fail to be achieved within one (1) year of the contractual New KHIE operations start date, the Contractor shall be liable for any damages resulting from its actions or inactions relating to the lack of certification. Should certification fail to be approved retroactively to the contractual New KHIE operational start date, the Contractor shall be liable for any damages resulting from its actions or inactions relating to the loss of maximum allowable enhanced FFP. Should de-certification of the New KHIE or any component part of either, occur prior to the end of the Contract period, the Contractor shall be liable for any damages resulting from its actions or inactions relating to the de-certification and loss of maximum allowable enhanced FFP.

For any violation of Section xx within this contract, the Contractor shall be liable for the Commonwealth and Federal dollar difference between the maximum allowable enhanced FFP and that actually received by the Commonwealth, including any losses due to lack of or loss of certification. All FFP penalty claims assessed by CMS or other Federal agencies shall be withheld from monies payable to the Contractor until all such penalty claims have been satisfied.

Phase I Legacy Replacement KHIE contractual operational start date is within six (6) months of contract execution

42

Report Card

Report Card Performance Requirement Reductions/Damages Measurement

Criteria & SLAs Status

1.4 DDI Milestones requires that the Contractor shall be required to:

Design, develop, test and implement a Phase I Legacy KHIE Replacement within six (6) months of contract execution.

Design, develop, test, and implement a Phase II New KHIE within one year of contract execution.

Accomplishment of certain specified KHIE DDI Phase activities by the key milestone dates, as defined and established in the approved KHIE DDI Phase Detailed Work Plan, shall be necessary to ensure full compliance with the start date. If, for any reason, the Contractor is delayed in meeting these key milestone dates and a Contract modification to the KHIE DDI Phase Detailed Work Plan is not approved, a reduction in compensation may be assessed. Approval of a Contract or KHIE DDI Phase Detailed Work Plan modification does not waive the Commonwealth's ability to impose damages and/or reductions in compensation if warranted by other terms of the Contract. The reductions in compensation listed in Subsection F. shall be in addition to any amounts assessed for delays in meeting the operational start date.

The Commonwealth may reduce compensation up to one thousand dollars ($1,000.00) per calendar day, or any part thereof, for each of the first ten (10) calendar days of delay in meeting a milestone date. The Commonwealth may reduce compensation up to two thousand dollars ($2,000.00) per calendar day, or any part thereof, for each of the next twenty (20) calendar days of delay in meeting a milestone date. The Commonwealth may reduce compensation up to three thousand dollars ($3,000.00) per calendar day, or any part thereof, for each additional calendar day of delay in meeting a milestone after thirty (30) calendar days.

Number of on-time milestones met by date/total number of milestones from agreed upon project plan. SLA expected greater than 100%.

1.5 DDI Deliverable Due Dates requires that copies of each deliverable, as defined in the approved New KHIE DDI Detailed Work Plan, shall be delivered to CHFS, in final form, in the number specified and on the date specified in the approved New KHIE DDI Detailed Work Plan. CHFS may require up to ten (10) paper copies and one (1) electronic copy of all deliverables. The electronic copy shall be compatible with Microsoft Word or other application software as requested by CHFS, and submitted on the Commonwealth-specified media. All deliverables shall be in a format approved by CHFS, and meet content and accuracy requirements specified or as subsequently defined by CHFS.

The Commonwealth may assess five hundred dollars ($500.00) for each calendar day, or any part thereof, that a deliverable is late, which includes providing less than the required copies or delivery on incorrect media. The Commonwealth may assess an additional five hundred dollars ($500.00) for each calendar day, or any part thereof, that a deliverable continues to not meet minimum content requirements or the approved format after its formal rejection by CHFS, when appropriate.

Number of on-time deliverables/total number of deliverables from agreed upon project plan. SLA expected greater than 100%.

43

Report Card

Report Card Performance Requirement Reductions/Damages Measurement

Criteria & SLAs Status

1.6 Contract End Key Turnover Milestone Dates - The Contractor shall be required to provide full support for system turnover activities in accordance with the CHFS approved Contractor Turnover Plan as follows: a) Assistance in turning over the complete and most current KHIE to the Commonwealth or its agent. b) Assistance and support in turnover activities necessary to affect an orderly, structured, smooth turnover to enable the CHFS and the new Contractor achieve successful transition of system operations to a new KHIE system operated by the Commonwealth or its agent. Accomplishment of certain specified turnover activities by key milestone dates, as established in the Commonwealth-approved KHIE Turnover Plan, shall be necessary to ensure full compliance with the start date. If, for any reason, the Contractor is delayed in meeting these key milestone dates and a Contract Modification to the KHIE Turnover Plan is not approved, a reduction in compensation may be assessed. Approval of a Contract or KHIE Turnover Plan modification does not waive the Commonwealth's ability to impose damages and/or reductions in compensation if warranted by other terms of the Contract. The reductions in compensation below shall be in addition to any amounts assessed for delays in meeting the operational start date.

The Commonwealth may reduce compensation up to one thousand dollars ($1,000.00) per calendar day, or any part thereof, for each of the first ten (10) calendar days of delay in meeting a milestone date. The Commonwealth may reduce compensation up to two thousand dollars ($2,000.00) per calendar day, or any part thereof, each of the next twenty (20) calendar days of delay in meeting a milestone date. The Commonwealth may reduce compensation up to three thousand dollars ($3,000.00) per calendar day, or any part thereof, for each additional calendar day of delay in meeting a milestone after thirty (30) days.

Number of on-time milestones met by date/total number of milestones from agreed upon project plan. SLA expected greater than 100%.

44

Report Card

Report Card Performance Requirement Reductions/Damages Measurement

Criteria & SLAs Status

1.7 Contract End Turnover Deliverable Due Dates - Copies of each deliverable, as defined in the Contract, shall be delivered to CHFS, when appropriate, in final form, in the number specified and on the date specified in the approved KHIE Turnover Plan. CHFS, when appropriate, may require one (1) up to ten (10) paper copies and one (1) electronic copy of all deliverables. The electronic copy shall be compatible with Microsoft Word or other application software as requested by CHFS, when appropriate, and submitted on the Commonwealth-specified media. All deliverables shall be in a format approved by CHFS, when appropriate, and meet content and accuracy requirements specified or as subsequently defined by CHFS, when appropriate.

The Commonwealth may assess up to five hundred dollars ($500.00) for each calendar day, or any part thereof, that a deliverable is late which includes providing less than the required copies or delivery on incorrect media. The Commonwealth may assess up to an additional five hundred dollars ($500.00) for each calendar day or any part thereof that a deliverable continues to not meet minimum content requirements or the approved format after its formal rejection by CHFS, when appropriate.

Number of on-time deliverables/total number of deliverables from agreed upon project plan. SLA expected greater than 100%.

1.8 Key Personnel - Key personnel commitments contained in the Contractor's proposal for all phases of the contract shall not be changed without prior written approval of the KHIE Contract Administrator, unless due to the death, disability, resignation, termination, or military recall or of any named individual. Staffing includes the staff proposed for all key positions required within this RFP at the levels of effort proposed or as specified in the Contract.

Anything less than 95% and the Commonwealth may assess up to ten thousand dollars ($10,000.00) in reduction in compensation for each key personnel proposed in the Contractor’s response to the RFP who is changed for reasons other than death, disability, resignation, termination, or military recall. The Commonwealth may assess up to an additional one thousand dollars ($1,000.00) in reduction in compensation per Commonwealth business day after the initial twenty-five (25) Commonwealth business days allowed for Contractor to find an acceptable replacement for the key personnel and an acceptable replacement has not provided.

Contractor staff retained during the course of project/Total Contractor staff assigned to the project in approved KHIE Staff Plan. SLA 95% or higher.

1.9 DDI Training – Address all required DDI training based on an approved CHFS training program for all KHIE, subsystems, functional components (systems and operations), interfaces, procedures, and confidentiality.

Beyond the SLA the Commonwealth may reduce compensation up to five hundred dollars ($500.00) for each ongoing training requirement not held within 30 days of the agreed upon training plan.

Training provided\training agreed and expected per training plan SLA is 95%

45

Report Card

Report Card Performance Requirement Reductions/Damages Measurement

Criteria & SLAs Status

1.10 Monthly DDI Performance Report Card - Within fifteen (15) calendar days of the end of each month during DDI, the Contractor shall be required to produce and deliver a report card on its actual performance as detailed herein. There are three (3) sections to the Report Card. The first section addresses all Contract requirements identified in this Contract. The second section lists each group of functional requirements which must be addressed. The third addresses any and all performance standards offered in the Contractor's proposal. Due to the changing environment, report card performance standard contract requirements and Vendor Supplied Measurements shall be reevaluated annually for appropriateness and any addition to the report card shall be finalized through joint negotiation between the Commonwealth and the Contractor.

The Commonwealth may reduce compensation up to one hundred dollars ($100.00) for each report card not meeting the SLA. Reduction in compensation may be imposed going forward, regardless of current month if back reports are still due and until the Contractor provides the Commonwealth all acceptable reporting due.

SLA is minimum of 95% of the reports delivered ten business days after the end of each month.

46

DDI Section 2 – Contract Functional Requirements

No. Solution Requirement Status 1. Registration

1.1 The new KHIE solution shall be configured so that the HIE has the ability to receive new patient demographics along with the Clinical System's MRN. The HIE loads this data to the MPI, which matches it to other records, and adds the Clinical System as a record location for the patient.

1.2 The new KHIE solution shall have the ability to perform patient registration based on any "feed". A "feed" is an ongoing submission of messages of a particular HL7 type and event form a particular source. For example, ADT^A03 messages form Hospital A is a separate feed from ADT^A08 messages from the same source.

2. Testing

2.1 The new KHIE solution shall test incoming data feeds from clinical systems to ensure that the proper specifications are being followed.

2.2 The system needs to test the HL7 clinical feeds from any potential CS prior to the CS being promoted to the production environment.

2.3 The vendor shall provide access to messages for onboarding verification. 3. Security

3.1 The new KHIE solution shall comply with all Commonwealth Security Standards detailed in section 30.040 of this RFP.

3.2 The new KHIE solution shall provide privacy and security components that follow national standards and meets all HIPAA security and privacy requirements.

3.3 The system hardware recommendations shall meet national security guidelines. 3.4 The data center where the solution is hosted shall be either NIST 800-53 rev. 3,

NIST 800-53 rev. 4 or FedRAMP certified.

3.5 The new KHIE solution shall secure the patient's data at all times and in all modules of the product (e.g. encrypted at rest, data encrypted in motion, data on handheld devices).

3.6 The new KHIE solution shall allow KHIE to configure or set the number of unsuccessful user logon attempts before locked out.

3.7 The new KHIE solution shall provide a "time out" feature that automatically signs off a user if a workstation has been left unattended for a user-configured time period.

3.8 The new KHIE solution shall support role based access. 3.9 The new KHIE solution shall provide different levels of security based on user role,

site, and/or enterprise settings.

3.10 The new KHIE solution shall permit the security administrator to set events that are considered security violations as well as provide real-time notification of any violations.

3.11 The new KHIE solution shall provide termination of user sessions/connections by an administrator if a breach is suspected.

3.12 The new KHIE solution shall have the ability to configure individual user interface components to exhibit the appropriate behavior based on the user's roles.

47

3.13

The system shall support protection of confidentiality of all Protected Health Information (PHI) delivered over the Internet or other known open and internal networks via encryption using type-DES(3DES) or the Advanced Encryption Standard (AES) and an open protocol such as TLS, SSL, IPSec, XML encryptions, or S/MINE or their successors.

3.14 In regards to 42 CFR, the system shall be able to protect the health information of the behavioral health record.

3.15

The Kentucky Online Gateway (KOG) (maintained by the Commonwealth) provides user provisioning and authorization services. The new KHIE solution shall utilize the KOG solution for user provisioning and authorization services. KHIE shall interface with KOG through Active Directory Federation Services (ADFS) for SSO (Single Sign-On). The solution shall be ADFS/WS Federation/Security Assertion Mark-Up Language (SAML) 2.0 compliant and use Claims for Authentication and Authorization. KOG supports both active (WS-Trust) and Passive (WS-Federation and SAML 2.0) scenarios. The new KHIE solution shall invoke KOG services prior to executing a user request from within the KHIE solution. The Vendor is responsible for the interface between the KHIE solution and the KOG.

3.16 The new KHIE solution shall support access based on SAML tokens and the claims encased therein. In addition, The new KHIE solution shall support global sign off in accordance to KOG specifications.

3.17 The new KHIE solution shall allow Kentucky to own the individual account certificates or they shall be transferable at a future date.

4. Security Logging and Audit 4.1 The new KHIE solution shall support the ATNA profile and TLS.

4.2 The new KHIE solution shall have the ability to provide audit logs/error logs to detect unauthorized access, activity, lockouts and automatically and proactively report to Commonwealth Security Staff.

4.3 The new KHIE solution shall have the ability to provide an audit trail that can be used to identify transactions or data accesses that have been performed. Examples are by date range, function, terminal, patient, and user.

4.4 The new KHIE solution shall have the ability to provide audit log reporting features. 5. Documentation

5.1 The vendor shall provide a documented process for their approach to custom software development regarding the user experience (workflow and branding) and the architecture, specifically, general and detailed systems design.

5.2

The vendor shall provide the following document deliverables: -Project Management Plan -Communications plan -General system design document -Connectivity guide -Detailed system design document -Data conversion plan -System test plan -Implementation plan -Provider migration plan -Operational support plan -Training plan -Provider test plan -Turnover plan

6. Infrastructure

48

6.1 The new KHIE solution shall support Web services access utilizing SOAP and TLS. 6.2 The new KHIE solution shall conduct routine backup procedures (or an equivalent)

without the users having to be off the system.

6.3 The new KHIE solution shall have the ability to provide common reporting tools and analytics that are compatible with recognized, industry standard reporting tools such as Business Objects, Cognos, Microsoft SSRS, etc.

6.4 The vendor shall provide load testing tools and load testing as part of their implementation.

6.5 The new KHIE solution shall be scalable to accommodate additional utilization, users, transactions and/or additional local/remote sites.

6.6 The new KHIE solution shall support multiple environments including development, test, QA, training and production.

6.7 The new KHIE solution shall provide monitoring of the HIE infrastructure and provide notification to KHIE administrators when errors or failures occur.

6.8 The new KHIE solution shall support the ability to receive data via secure Web Services, VPN, and Minimal Low Level Protocol (MLLP) over Virtual Private Network.

6.9 The new KHIE solution shall maintain Infrastructure standards certification of ISO/IEC 27002.

6.10 The new KHIE solution shall have the capability to be securely accessed from any location with an internet/broadband connection and is compatible with current leading web browsers such as IE, Chrome, Firefox.

6.11 Upon system turnover all information shall be made available to the successful bidder in XML, X-12, HL7, CSV, or comma delimited text or other means as mutually agreed upon by the vendors and the Commonwealth.

6.12 The new KHIE solution shall be covered under Vendor's Business Continuity and Disaster Recovery plan.

6.13 The new KHIE solution shall support and implement redundancy/fault tolerance for system availability.

6.14 The new KHIE solution shall conduct routine backup procedures (or an equivalent) without the users having to be off the system.

6.15

The new KHIE solution shall receive feeds of claims data from various MCO's and the Commonwealth's Medicaid Fiscal Agent. The new KHIE solution shall change the format of the data from administrative to clinical, summarize, and then filter. The new KHIE solution shall parse the claims data into the CDR in order to share it through the Provider Portal and IHE documents. Data will be provided daily through file exchange or, in some cases, in real-time by way of web services. Claims can be reversed or adjusted requiring HIE to process updates. The new KHIE solution shall process these updates as they are received and in the order in which they occurred on the source system. The Commonwealth will provide a means by which this order can be determined.

6.16 The new KHIE solution shall be able to export data to the Kentucky Health Data Trust by way of a real time data feed or batch file notification.

6.17 The new KHIE solution shall support the following document types: - CCD -CCDA -Any future IHE standards

49

6.18

The new KHIE solution shall support a variety of data input methods including but not limited to: -HL7 messages -Healthcare Medical and Pharmacy claims -Dental claims -HL7 Clinical Documents such as C-CDA -IHE profiles

6.19 The vendor shall provide future software releases and updates to all applications as part of regular maintenance fees.

6.20 The new KHIE solution shall provide a method for archiving patient health information, and all supporting electronic files (including application software files)

6.21 The vendor shall provide a schedule for routine maintenance as well as providing a notification method for scheduled system maintenance.

6.22 The vendor shall provide a documented process for notifying KHIE and all participating providers of any planned feed outages.

6.23 The vendor shall provide a documented process for performing all emergency maintenance to the system.

6.24 The new KHIE solution shall support industry standard including HL7, CCR, CCD, and CDA at a minimum.

6.25 The new KHIE solution shall support standard HL7 interfaces. 6.26 The new KHIE solution shall have the ability to interface via HL7 compatible

interface for receiving ADT information.

6.27 The new KHIE solution shall allow users to view a display of archived transactions and audit file as well as the transactions as they are being processed.

6.28 The new KHIE solution shall provide its own eMPI, which can be any technology of the implementer’s choice so long as it is capable of registering entities with the Commonwealth's Master Data Management (MDM) solution, which is IBM's MDM product.

6.29 The new KHIE solution shall have the ability to account for and log any records that were merged and unmerged based on algorithms. This information shall be made available to the KHIE staff on demand.

7. Performance Reliability

7.1 The new KHIE solution shall provide performance metrics for measuring application availability, performance, and network connectivity.

7.2 The new KHIE solution shall have the ability to manage sudden demand surges without adversely affecting system use.

7.3

The new KHIE solution shall receive feeds of claims data from various MCO's and the Commonwealth's Medicaid Fiscal Agent. The new KHIE solution shall change the format of the data from administrative to clinical, summarize, and then filter. The new KHIE solution shall parse the claims data into the CDR in order to share it through the Provider Portal and IHE documents. Data will be provided daily through file exchange or, in some cases, in real-time by way of web services. Claims can be reversed or adjusted requiring HIE to process updates. The new KHIE solution shall process these updates as they are received and in the order in which they occurred on the source system. The Commonwealth will provide a means by which this order can be determined.

7.4 The new KHIE solution shall have a provider portal which allows providers access to both the query functionality and to the Direct.

50

7.5 The online transactions shall average below three (3) seconds or less response time for all non-reporting functions. The response time for all non-reporting functions shall not exceed thirty (30) seconds at any time.

7.6 The systems patient matching logic shall allow for customizations which would be unique to KHIE if desired. This must be explained and demonstrated.

8. Public Health Reporting

8.1 The new KHIE solution shall support direct pass-through of immunization updates, history queries and query responses as defined in the Center for Disease Control HL7 2.3.1 and above Implementation Guide for Immunization Messaging.

8.2 The new KHIE solution shall be configured to forward all Syndromic Surveillance messages from HIE to subscribing systems such as Biosense.

8.3 The new KHIE solution shall be configured to utilize the ADT information contained in SS messages for patient identification and forward the SS messages to subscribing systems such as Biosense in accordance with CDC Syndromic Surveillance specifications.

8.4

The new KHIE solution shall receive lab result HL7 messages from connected lab and provider systems, include that information in the CDR determine what is reportable to NEDSS according to DPH specifications, and output an appropriate message to be consumed by NEDSS via PHIN-MS following industry standards for Electronic Laboratory Reporting.

8.5 The new KHIE solution shall receive and forward cancer case data to the Kentucky Cancer Registry (CR).

9. IHE 9.1 The new KHIE solution shall support standard web service connectivity for IHE

profiles.

9.02 The new KHIE solution shall allow providers to send documents to the HIE where they can be registered, stored, and shared with other providers. The system must be able to accept, index, and repose these documents.

9.3 The new KHIE solution shall be able to create an on-demand CDA/C-CDA document that is registered in the XDS.b environment. The document will be composed of data from the CDR on a specified patient.

9.4

The new KHIE solution shall be able to access data from a separate community by way of IHE XCA profile. The providers EHR system will query KHIE's document repository, prompting a query of other communities from the repository. Any documents found on the patient are listed in the return message to the EHR. If a particular document is requested, the KHIE system will retrieve and deliver the document.

9.5 KHIE needs to connect to e-Health Exchange; therefore needs to be HealtheWay certified.

9.6 The new KHIE solution shall be able to insert all Medicaid claims information collected in the CDR into the Generate On-Demand functionality.

9.7

The new KHIE solution shall be configured to support the Provide X-User Assertion [ITI-40] transaction. This transaction is utilized by the X-Service User to pass a claimed identity assertion to the X-Service Provider. The X-Service User and the X-Service Provider use the X-Assertion Provider as the third party issuer of the claimed identity assertion.

10. Query Based Exchange

51

10.1

When queried, the system shall return all matching patients with sufficient demographics to extinguish any ambiguities. Once the patient is selected, the system shall display the available documents being either static or dynamic. If the provider selects a static document, the system shall retrieve the document form the document repository. If the provider chooses a dynamic document, the system shall gather the clinical information from the CDR and create the requested clinical document.

10.2

The new KHIE solution shall support returning documents to an external personal health record (PHR) system implemented by the state which provides a standard IHE based Query. It shall send the available static and dynamic documents to the PHR for the PHR to display in its own environment. The PHR will be able to provide the proposed system with a unique identifier for each patient queried.

10.3 The new KHIE solution shall support that all queries also query the immunization registry using Query By Parameter (QBP) as specified by the Commonwealth during JAD sessions in order that the immunization history result is included in KHIE query results.

10.4

The new KHIE solution shall have the ability to receive clinical messages in HL7 format from various providers in order to support the community health record. The data being sent is matched to the existing patient; additionally, the clinical data is then parsed and stored in the CDR. In the event that a clinical message is sent pertaining to a patient that has not been registered the solution shall at least store the message in an error queue and bring it to the attention of the KHIE technical staff. However if matching information is available it should be used to match the record if possible.

10.5 The new KHIE solution shall programmatically monitor and perform a nightly cleanup of the error queue using any newly available information in the MPI.

11. Directed Exchange

11.1

The new KHIE solution shall include but not limited to the following Direct features and functions: -Direct Addresses -Security and Trust Authority Services -DIRECT Messages (RFC 5322) - Message Transport & Delivery - Simple Mail Transport Protocol (SMTP) -Provider Directory

11.2 The new KHIE solution shall be Direct Trusted Agent Accreditation Program (DTAAP) accredited.

11.3 The Vendor shall ensure the minimum DTAAP identification and provisioning process steps are in place prior to issue of an X.509 certificate. (note that these are minimum requirements)

11.4 In the new KHIE solution certificate discovery shall occur prior to a DIRECT message being sent in order to fulfill the encryption functions of the S/MIME format. Discovery must be based on existing Internet protocols (existing specifications for discovery via DNS (If DNS is not supported, an alternate method must be offered)).

11.5 The new KHIE solution shall support automated certificate publication and resolution that operates intra and inter HISP.

11.6 The new KHIE solution shall afford KHIE the ability to provide HISP services to Clinical Systems who are XDR enabled and HISP agnostic. Additionally, the system shall be able to report separately the messages that have XDR to SMTP translation.

52

11.7 The new KHIE solution shall associate Direct accounts created within the new KHIE solution and their associated certificates generated with a DIRECT domain to be determined by KHIE (e.g. [email protected]).

11.8 The new KHIE solution shall define the options available for single year and multi-year cycles for Direct accounts created within the new KHIE solution and associated certificates generated for them.

11.9 The new KHIE solution shall be able to add external non-DTAAP accredited HISPs as trusted entities at the direction of KHIE.

11.10 The new KHIE solution shall support routing and delivery of valid Secure/Multipurpose Internet Mail Extensions (S/MIME) payload types (e.g. HL7 messages, CCD/CCR, PDF, Word Document, etc.).

11.11 The new KHIE solution shall be able to format the “payload” as an Internet Message Format (IMF) RFC5322-compliant email message with a valid MIME body (RFC 2045, RFC 2046).

11.12 The new KHIE solution shall demonstrate routing (inter and intra HISP) transactions originated from any DIRECT account within and outside of the domain.

11.13

The new KHIE solution shall support DIRECT-compliant gateways that implement the Applicability Statement for Secure Health Transport specification while harmonizing local standards/mechanisms to DIRECT-equivalents. (e.g., XDR and XDM for Direct Messaging specify such a solution when using IHE XDR for local transport, ITI and S&I). http://wiki.directproject.org/Applicability+Statement+for+Secure+Hea%20lth+Transport

11.14 The Vendor shall provide a list of all EHR systems to which they have developed DIRECT messaging interfaces and describe those that are currently live and any that are planned, including the technical details of how this is accomplished.

11.15 The new KHIE solution shall provide automatic notification of the receipt of a new DIRECT message to a user's regular email account.

11.16 The new KHIE solution shall operationalize the ONC July 2012 Implementation Guidelines for State HIE Grantees on Direct Infrastructure & Security/Trust Measure for Interoperability.

11.17 The new KHIE solution shall provide a Provider Directory for DIRECT users that are established accounts within the Direct environment.

11.18

The new KHIE solution shall provide a template for the KHIE staff to use to import file extracts from external "regional" provider directories. The import function and template shall allow for Add, Replace or Empty and be separate from the internal established accounts. It should allow for additional user defined fields which are not required and beyond the required set.

11.19 The new KHIE solution shall provide the ability for a user to export the entire provider directory or user-selected portion of the directory for import into an EHR system.

11.20 The new KHIE solution shall comply with ONC supported standards direction related to Provider Directory services. These may include ASC X12 Transaction 274 and 275, and /or IHE XD*. The Vendor shall present material in regard to their involvement in and tracking on these evolving standards initiatives.

53

11.21

The new KHIE solution shall be able to establish and maintain relationships between individuals and entities (individuals associated with 1 or many entities) as appropriate (e.g., Dr. X at Clinic A), following the recommendations and standards established through the ONC. The directory should support multiple DIRECT addresses for an individual or entity.

11.22 The new KHIE solution shall provide a folder level export of all active mailboxes upon contract termination.

11.23 The new KHIE solution shall support resolution of DIRECT Addresses issued by KHIE and other certificate granting authorities issuing DIRECT addresses (e.g. [email protected], [email protected], [email protected]).

11.24 The new KHIE solution shall support distributed granting (certificate assigned to an entity who assigns to employees) of X509 V3 certificates to trusted nodes/entities and align trust structure for these certificates as part of the Provider Directory.

11.25 The new KHIE solution shall support the ability to serve as proxy for a certified individual or entity, at the request of that individual or entity based on local storage of a private key for that individual or entity.

11.26 The new KHIE solution shall automatically assess and evaluate trustworthiness of certificates issued by Certificate Authorities that are routed by other HISPs presented in the course of sending and receiving messages DIRECT Messages.

12. Event Notification

12.1

The new KHIE solution shall have the capability to send an immediate or batch notification of event(s) (Alert) using pre-determined and configurable rules. The recipients will vary based on their role in treatment and/or their relationship to the patient and a flexible delivery of those events is required including but not limited to Direct message, file transfer to a clinical system or other system, text message, or web portal. Examples of these events of interest include ER admissions and discharges, inpatient stay admissions and discharges, and level of care changes. Each event must be able to generate one or multiple notifications possibly delivered through multiple routes.

12.2 The new KHIE solution shall have the capability to send an immediate or batch notification of event(s) using pre-determined rules based on the entire HIE data set, including Medicaid Claims data. Prefer a flexible delivery of those events including but not limited to Direct message, or file transfer.

12.3

The vendor shall configure the system to send notifications base on specific Admit, Transfer and Discharge codes for those systems which are providing ADT data feeds. The sending of these ADT notifications will be rule based and at a minimum provide: -Patient's name -Patient's location -Diagnosis -ADT specifications

12.4 The new KHIE solution shall allow the generation of alert messages that can be configured by the time of day and day of week, for each interface via user-defined peak, off-peak and scheduled downtimes.

54

12.5

The new KHIE solution shall support detecting when a patient is re-admitted to any connected hospital within 30 days of discharge from that or another connected hospital and report that event to the original discharging hospital. The new KHIE solution shall be configurable to be selective on the diagnosis at discharge. For example, a patient is discharged after being hospitalized for pneumonia. A week has passed and they are still feeling ill, prompting them to return to the original or any other connected hospital for further care.

12.6

The new KHIE solution shall support detecting when a patient is re-admitted to any connected mental health facility within 30 days of discharge from that or another connected mental health facility and report that event to the original discharging facility. The new KHIE solution shall be configurable to be selective on the diagnosis at discharge and readmission.

13. HIE Monitoring and Reporting

13.1 The new KHIE solution shall have error monitoring with notification message options including stored and viewable online and can be routed via various mechanisms such as e-mail and texts.

13.2 The new KHIE solution shall include a variety of monitoring and troubleshooting tools that allow the responsible KHIE staff to immediately identify and correct any problem that are encountered. These intuitive tools are easy to access and use via "point and click" or "drag and drop" features.

13.3

The new KHIE solution shall provide reports showing traffic/usage of Direct, to include but not limited to XDR traffic by participating Clinical Systems. The new KHIE solution shall have the ability to capture all incoming raw data feed messages and capture all outgoing messages that are delivered to other systems (Immunization Registry, Biosense, NEDSS, Cancer Registry)

13.4 The new KHIE solution shall report on all cross gateway queries supported by [ITI-38] transaction. The report should contain the home Community id of the requesting gateway and the data that was sent supported by [ITI-39] transaction to the requesting gateway.

13.5 The new KHIE solution shall all authorized KHIE staff to be able to export data to the Kentucky Health Data Trust by way of a batch file or be able to have a real time data feed.

13.6

The new KHIE solution shall have a performance/service and metrics dashboard to provide accessibility to overall as well as specific items of system health. The information provided shall include but not be limited to: -Active users (identifiable by user id and health system affiliation) -Daily activity reports including: a. Number of messages going through KHIE's HISP b. Active data feeds (with error reporting capability) c. Daily query information (submitted documents, queries performed, returned empty data sets) -Meaningful Use Reporting (monthly) a. For each provider that has submitted a Summary of Care CCD, the system shall log the queries for each Summary of Care CCD that were made by another provider. -System performance metrics (query response time, data feed health monitoring)

13.7 The new KHIE solution shall be configured so that it enables the KHIE staff to filter reports from the dashboard by data feed and provider NPIs.

55

DDI Section 3 – Vendor Supplied Measurements

Report Card #

Response Reference Report Card Performance Requirement Performance This Month Status

1 2

3 4 5 6 7 8 9

10

56

40.13 Contractor Cooperation in Related Efforts

The Commonwealth of Kentucky may undertake or award other contracts for additional or related work, services, supplies, or commodities, and the contractor shall fully cooperate with such other contractors and Commonwealth employees. The contractor shall not commit or permit any act that will interfere with the performance of work by any other contractor or by Commonwealth employees.

40.14 Contractor Affiliation

"Affiliate" shall mean a branch, division or subsidiary that is effectively controlled by another party. If any affiliate of the contractor shall take any action that, if done by the contractor, would constitute a breach of this agreement, the same shall be deemed a breach by such party with like legal effect.

40.15 Commonwealth Property

The contractor shall be responsible for the proper custody and care of any Commonwealth-owned property furnished for contractor's use in connections with the performance of this contract. The contractor shall reimburse the Commonwealth for its loss or damage, normal wear and tear excepted.

40.16 Confidentiality of Contract Terms

The contractor and the Commonwealth agree that all information communicated between them before the effective date of the contract shall be received in strict confidence and shall not be necessarily disclosed by the receiving party, its agents, or employees without prior written consent of the other party. Such material will be kept confidential subject to Commonwealth and Federal public information disclosure laws.

Upon signing of the contract by all parties, terms of the contract become available to the public, pursuant to the provisions of the Kentucky Revised Statutes.

The contractor shall have an appropriate agreement with its subcontractors extending these confidentiality requirements to all subcontractors’ employees.

40.17 Confidential Information

The contractor shall comply with the provisions of the Privacy Act of 1974 and instruct its employees to use the same degree of care as it uses with its own data to keep confidential information concerning client data, the business of the Commonwealth, its financial affairs, its relations with its citizens and its employees, as well as any other information which may be specifically classified as confidential by the Commonwealth in writing to the contractor. All Federal and State Regulations and Statutes related to confidentiality shall be applicable to the contractor. The contractor shall have an appropriate agreement with its employees, and any subcontractor employees, to that effect, provided however, that the foregoing will not apply to:

57

A. Information which the Commonwealth has released in writing from

being maintained in confidence; B. Information which at the time of disclosure is in the public domain

by having been printed an published and available to the public in libraries or other public places where such data is usually collected; or

C. Information, which, after disclosure, becomes part of the public domain as defined above, thorough no act of the contractor.

40.18 Advertising Award

The contractor shall not refer to the award of contract in commercial advertising in such a manner as to state or imply that the firm or its services are endorsed or preferred by the Commonwealth of Kentucky without the expressed written consent of the agency technical contact person. (see Section 50.4)

40.19 Patent or Copyright Infringement The contractor shall report to the Commonwealth promptly and in reasonable written detail, each notice of claim of patent or copyright infringement based on the performance of this contract of which the contractor has knowledge.

The Commonwealth agrees to notify the contractor promptly, in writing, of any such claim, suit or proceeding, and at the contractor's expense give the contractor proper and full information needed to settle and/or defend any such claim, suit or proceeding.

If, in the contractor's opinion, the equipment, materials, or information mentioned in the paragraphs above is likely to or does become the subject of a claim or infringement of a United States patent or copyright, then without diminishing the contractor's obligation to satisfy any final award, the contractor may, with the Commonwealth's written consent, substitute other equally suitable equipment, materials, and information, or at the contractor's options and expense, obtain the right for the Commonwealth to continue the use of such equipment, materials, and information.

The Commonwealth agrees that the contractor has the right to defend, or at its option, to settle and the contractor agrees to defend at its own expense, or at its option to settle, any claim, suit or proceeding brought against the Commonwealth on the issue of infringement of any United States patent or copyright or any product, or any part thereof, supplied by the contractor to the Commonwealth under this agreement. The contractor agrees to pay any final judgment entered against the Commonwealth on such issue in any suit or proceeding defended by the contractor.

58

If principles of governmental or public law are involved, the Commonwealth may participate in the defense of any such action, but no costs or expenses shall be incurred for the account of the contractor without the contractor's written consent. The contractor shall have no liability for any infringement based upon:

A. the combination of such product or part with any other product or

part not furnished to the Commonwealth by the contractor B. the modification of such product or part unless such modification

was made by the contractor C. the use of such product or part in a manner for which it was not

designed

40.20 Permits, Licenses, Taxes and Commonwealth Registration The contractor shall procure all necessary permits and licenses and abide by all applicable laws, regulations, and ordinances of all Federal, State, and local governments in which work under this contract is performed.

The contractor shall maintain certification of authority to conduct business in the Commonwealth of Kentucky during the term of this contract. Such registration is obtained from the Secretary of State, who will also provide the certification thereof. However, the contractor need not be registered as a prerequisite for responding to the RFP. Additional local registration or license may be required.

The contractor shall pay any sales, use, and personal property taxes arising out of this contract and the transaction contemplated hereby. Any other taxes levied upon this contract, the transaction, or the equipment or services delivered pursuant hereto shall be borne by the contractor.

40.21 EEO Requirements The Equal Employment Opportunity Act of 1978 applies to All State government projects with an estimated value exceeding $500,000. The contractor shall comply with all terms and conditions of the Act.

http://finance.ky.gov/services/eprocurement/Pages/VendorServices.aspx.

40.22 Provisions for Termination of the Contract Any contract resulting from this solicitation shall be subject to the termination provisions set forth in 200 KAR 5:312.

40.23 Bankruptcy

In the event the contractor becomes the subject debtor in a case pending under the Federal Bankruptcy Code, the Commonwealth's right to terminate this contract may be subject to the rights of a trustee in bankruptcy to assume or assign this contract. The trustee shall not have the right to assume or assign this contract unless the trustee (a) promptly cures all defaults under this contract; (b)

59

promptly compensates the Commonwealth for the monetary damages incurred as a result of such default, and (c) provides adequate assurance of future performance, as determined by the Commonwealth.

40.24 Conformance with Commonwealth & Federal Laws/Regulations

This contract is subject to the laws of the Commonwealth of Kentucky and where applicable Federal law. Any litigation with respect to this contract shall be brought in state or federal court in Franklin County, Kentucky in accordance with KRS 45A.245.

40.25 Accessibility

Vendor hereby warrants that the products or services to be provided under this contract comply with the accessibility requirements of Section 504 of the Rehabilitation Act of 1973, as amended (29 U.S.C. § 794d), and its implementing regulations set forth at Title 36, Code of Federal Regulations, part 1194. Vendor further warrants that the products or services to be provided under this contract comply with existing federal standards established under Section 255 of the Federal Telecommunications Act of 1996 (47 U.S.C. § 255), and its implementing regulations set forth at Title 36, Code of Federal Regulations, part 1193, to the extent the vendor's products or services may be covered by that act. Vendor agrees to promptly respond to and resolve any complaint regarding accessibility of its products or services which is brought to its attention.

40.26 Access to Records

The contractor, as defined in KRS 45A.030 (9) agrees that the contracting agency, the Finance and Administration Cabinet, the Auditor of Public Accounts, and the Legislative Research Commission, or their duly authorized representatives, shall have access to any books, documents, papers, records, or other evidence, which are directly pertinent to this contract for the purpose of financial audit or program review. Records and other prequalification information confidentially disclosed as part of the bid process shall not be deemed as directly pertinent to the contract and shall be exempt from disclosure as provided in KRS 61.878(1)(c). The contractor also recognizes that any books, documents, papers, records, or other evidence, received during a financial audit or program review shall be subject to the Kentucky Open Records Act, KRS 61.870 to 61.884.

40.27 Prohibitions of Certain Conflicts of Interest In accordance with KRS 45A.340, the contractor represents and warrants, and the Commonwealth relies upon such representation and warranty, that it presently has no interest and shall not acquire any interest, direct or indirect, which would conflict in any manner or degree with the performance of its services. The contractor further represents and warrants that in the performance of the contract, no person, including any subcontractor, having any such interest shall be employed.

60

In accordance with KRS 45A.340 and KRS 11A.040 (4), the contractor agrees that it shall not knowingly allow any official or employee of the Commonwealth who exercises any function or responsibility in the review or approval of the undertaking or carrying out of this contract to voluntarily acquire any ownership interest, direct or indirect, in the contract prior to the completion of the contract.

40.28 No Contingent Fees

No person or selling agency shall be employed or retained or given anything of monetary value to solicit or secure this contract, excepting bona fide employees of the offeror or bona fide established commercial or selling agencies maintained by the offeror for the purpose of securing business. For breach or violation of this provision, the Commonwealth shall have the right to reject the proposal or cancel the contract without liability.

40.29 Vendor Response and Proprietary Information

The RFP specifies the format, required information, and general content of proposals submitted in response to the RFP. The Finance and Administration Cabinet will not disclose any portions of the proposals prior to Contract Award to anyone outside the Finance and Administration Cabinet, representatives of the agency for whose benefit the contract is proposed, representatives of the Federal Government, if required, and the members of the evaluation committees. After a contract is awarded in whole or in part, the Commonwealth shall have the right to duplicate, use, or disclose all proposal data submitted by vendors in response to this RFP as a matter of public record. Although the Commonwealth recognizes the vendor's possible interest in preserving selected data which may be part of a proposal, the Commonwealth must treat such information as provided by the Kentucky Open Records Act, KRS 61.870 et sequitur. Informational areas which normally might be considered proprietary shall be limited to individual personnel data, customer references, selected financial data, formulae, and financial audits which, if disclosed, would permit an unfair advantage to competitors. If a proposal contains information in these areas that a vendor declares proprietary in nature and not available for public disclosure, the vendor shall declare in the Transmittal Letter [see Section 60.6 (A)] the inclusion of proprietary information and shall noticeably label as proprietary each sheet containing such information. Proprietary information shall be submitted under separate sealed cover marked “Proprietary Data”. Proposals containing information declared by the vendor to be proprietary, either in whole or in part, outside the areas listed above may be deemed non-responsive to the RFP and may be rejected. The Commonwealth of Kentucky shall have the right to use all system ideas, or adaptations of those ideas, contained in any proposal received in response to this RFP. Selection or rejections of the proposal will not affect this right.

61

40.30 Contract Claims The Parties acknowledge that KRS 45A.225 to 45A.290 governs contract claims.

40.31 Limitation of Liability The liability of the Commonwealth related to contractual damages is set forth in KRS 45A.245.

40.32 Discrimination (Effective April 8, 2015) Discrimination (because of race, religion, color, national origin, sex, sexual orientation, gender identity, age, or disability) is prohibited. This section applies only to contracts utilizing federal funds, in whole or in part. During the performance of this contract, the contractor agrees as follows:

1. The contractor will not discriminate against any employee or applicant for employment because of race, religion, color, national origin, sex, sexual orientation, gender identity, or age. The contractor further agrees to comply with the provisions of the Americans with Disabilities Act (ADA), Public Law 101-336, and applicable federal regulations relating thereto prohibiting discrimination against otherwise qualified disabled individuals under any program or activity. The contractor agrees to provide, upon request, needed reasonable accommodations. The contractor will take affirmative action to ensure that applicants are employed and that employees are treated during employment without regard to their race, religion, color, national origin, sex, sexual orientation, gender identity, age or disability. Such action shall include, but not be limited to the following; employment, upgrading, demotion or transfer; recruitment or recruitment advertising; layoff or termination; rates of pay or other forms of compensations; and selection for training, including apprenticeship. The contractor agrees to post in conspicuous places, available to employees and applicants for employment, notices setting forth the provisions of this non-discrimination clause.

2. The contractor will, in all solicitations or advertisements for employees placed by or on behalf of the contractor; state that all qualified applicants will receive consideration for employment without regard to race, religion, color, national origin, sex, sexual orientation, gender identity, age or disability.

3. The contractor will send to each labor union or representative of workers with which he has a collective bargaining agreement or other contract or understanding, a notice advising the said labor union or workers' representative of the contractor's commitments under this section, and shall post copies of the notice in conspicuous places available to employees and applicants for employment. The contractor will take such action with respect to any subcontract or purchase order as the administering agency may direct as a means of enforcing such provisions, including sanctions for noncompliance.

62

4. The contractor will comply with all provisions of Executive Order No. 11246 of September 24, 1965 as amended, and of the rules, regulations and relevant orders of the Secretary of Labor.

5. The contractor will furnish all information and reports required by Executive Order No. 11246 of September 24, 1965, as amended, and by the rules, regulations and orders of the Secretary of Labor, or pursuant thereto, and will permit access to his books, records and accounts by the administering agency and the Secretary of Labor for purposes of investigation to ascertain compliance with such rules, regulations and orders.

6. In the event of the contractor's noncompliance with the nondiscrimination clauses of this contract or with any of the said rules, regulations or orders, this contract may be cancelled, terminated or suspended in whole or in part and the contractor may be declared ineligible for further government contracts or federally-assisted construction contracts in accordance with procedures authorized in Executive Order No. 11246 of September 24, 1965, as amended, and such other sanctions may be imposed and remedies invoked as provided in or as otherwise provided by law.

7. The contractor will include the provisions of paragraphs (1) through (7) of section 202 of Executive Order 11246 in every subcontract or purchase order unless exempted by rules, regulations or orders of the Secretary of Labor, issued pursuant to section 204 of Executive Order No. 11246 of September 24, 1965, as amended, so that such provisions will be binding upon each subcontractor or vendor. The contractor will take such action with respect to any subcontract or purchase order as the administering agency may direct as a means of enforcing such provisions including sanctions for noncompliance; provided, however, that in the event a contractor becomes involved in, or is threatened with, litigation with a subcontractor or vendor as a result of such direction by the agency, the contractor may request the United States to enter into such litigation to protect the interests of the United States.

SECTION 50 – SCOPE OF WORK 50.1 Agencies to Be Served

This contract shall be for use by the CABINET FOR HEALTH & FAMILY SERVICES. No shipments shall be made except upon receipt by vendor of an official delivery order from the using agency.

The Office of Procurement Services reserves the right, with the consent of the vendor, to offer the Master Agreement resulting from this solicitation to other state agencies requiring the product(s) or service(s).

50.2 Term of Contract and Renewal Options

63

The initial term of the contract shall be for a period of three (3) years from the effective date of the Award of Contract.

This contract may be renewed at the completion of the initial contract period for two (2) additional two (2) year periods upon the mutual agreement of the Parties. Such mutual agreement shall take the form of a contract modification as described in Section 40.8 of this RFP.

At the end of the contract, the vendor shall provide all agency data in a form that can be converted to any subsequent system of the agency’s choice. The vendor shall cooperate to this end with the vendor of the agency’s choice, in a timely and efficient manner.

The Commonwealth reserves the right not to exercise any or all renewal options. The Commonwealth reserves the right to extend the contract for a period less than the length of the above-referenced renewal period if such an extension is determined by the Commonwealth Buyer to be in the best interest of the Commonwealth.

The Commonwealth reserves the right to renegotiate any terms and/or conditions as may be necessary to meet requirements for the extended period. In the event proposed revisions cannot be agreed upon, either party shall have the right to withdraw without prejudice from either exercising the option or continuing the contract in an extended period.

50.3 Basis of Price Revisions

PRICE ADJUSTMENTS: Unless otherwise specified, the prices established by the contract resulting from this solicitation shall remain firm for the contract period subject to the following:

A: Price Increases: A price increase shall not occur during the first twelve (12) months of the contract. A vendor may request a price increase after twelve (12) months of the contract, which may be granted or denied by the Commonwealth. Any such price increase shall be based on industry wide price changes. The contract holder must request in writing a price increase at least thirty (30) days prior to the effective date, and shall provide firm proof that the price increase(s) is justified. The Office of Procurement Services may request additional information or justification. If the price increase is denied, the contract holder may withdraw from the contract without prejudice upon written notice and approval by the Office of Procurement Services. Provided, however, that the vendor must continue service, at the contract prices, until a new contract can be established (usually within sixty (60) days).

B: Price Decreases: The contract price shall be reduced to reflect any industry wide price decreases. The contract holder is required to furnish

64

the Office of Procurement Services with notice of any price decreases as soon as such decreases are available.

C: Extended Contract Periods: If the contract provides for an optional renewal period, a price adjustment may be granted at the time the contract is renewed, subject to price increase justification as required in Paragraph A “Price Increases” as stated above.

50.4 Notices

After the award of contract, all programmatic communications with regard to day-to-day performance under the contract are to be made to the agency technical contact(s) identified during the negotiation phase of this procurement. After the award of contract, all communications of a contractual or legal nature are to be made to the Commonwealth Buyer.

50.5 Subcontractors

The contractor is permitted to make subcontract(s) with any other party for furnishing any of the work or services herein. The contractor shall be solely responsible for performance of the entire contract whether or not subcontractors are used. The Commonwealth shall not be involved in the relationship between the prime contractor and the subcontractor; however, before engaging a subcontractor not identified in the contractor’s response or replacing a subcontractor identified in the contractor’s response, the contractor will notify the agency and provide the agency with information regarding the proposed subcontractor’s relevant qualifications, experience and key personnel. The agency reserves the right to approve any subcontractor proposed by the prime contractor; such approval shall not be unreasonably withheld. Any issues that arise as a result of the contractor’s relationship(s) with its subcontractors shall be resolved by the prime contractor. All references to the contractor shall be construed to encompass both the contractor and any subcontractors of the contractor.

50.6 Scope of Work/Technical Requirements

The CHFS, Kentucky Office of Health Benefit and Information Exchange is seeking a Vendor(s) to provide a hosted and configurable Software as a Service (SaaS) solution for the Kentucky Health Information Exchange system that the vendor will configure and customize as necessary to meet the requirements as defined in this RFP and attachments. The vendor shall be responsible for hosting the solution and shall provide the services associated with support and maintenance of the system. CHFS is utilizing NIST Special Publication 800-145 as a definition for SaaS, as well as hosted environments. Responding vendors shall also use NIST Special Publication 500-293 for guidance on the US Government Cloud Computing Technology Roadmap as a guide for the implementation of cloud computing components.

65

The system will receive clinical data and healthcare claims based data and store it in a way that keeps it distinguished by source. From this data, the system must generate a C-CDA document on demand and deliver it via query-based and directed exchanges. In addition, the C-CDA must include the latest data from the Kentucky Immunization Registry (IR) as a source. In addition, this RFP requires the ability to route messages to any valid endpoint such as the IR, Cancer Registry (CR), or the National Electronic Disease Surveillance System NEDSS, with or without validation and translation. The Commonwealth plans to use this capability to allow providers to send messages to systems within the Kentucky Department for Public Health (KDPH). This RFP also requires a Direct Secure Messaging (DSM) implementation with full HISP capabilities that features both an online user interface as well as direct integration with clinical systems. Provider organizations must be able to perform self-service maintenance functions, in particular, maintenance of their provider directory. The Commonwealth plans to use the DSM solution for peer-to-peer communications and to deliver proactive messages to providers. Summary of requirements detailed within this RFP (some, but not necessarily all, reference locations): A. Exchange of clinical summaries including data contained in the Central Data

Repository (CDR) as well as other available state systems (50.7.2.5 and 50.7.2.7)

B. Provider to Provider communications (50.7.2.4) C. HIE to HIE communications (50.7.2.10) D. Implementation and use of IHE profiles (50.7.2.10) E. Adherence to current applicable NIST standards (30.12, 50.7, 50.7.2.6,

60.5.C.9 f) F. Event Notification System capabilities for alerting (50.7.2.11) G. Support Public Health quality improvement efforts (50.7.1.1, 50.7.1.9,

50.7.2.3) H. Support EHR Incentive Program Meaningful Use Measures (50.7.1.1,

50.7.1.9, 50.7.2.3) I. Support both active and passive pass-through to state registries (50.7.1.1,

50.7.1.9, 50.7.2.3) J. HealtheWay certification for connectivity to eHealth Exchange (50.7.2.10) K. Support Opt Out consent management (50.7.2.6) L. Support forthcoming consent granularity standards for specially protected

health information (50.7.2.5 and 50.7.2.7) M. Portal access to the available patient data thereby providing a longitudinal

virtual health record (50.7.2.13) N. Provide available patient data to Kentucky’s Personal Health Record system

(50.7.2.13)

66

O. Direct standards (50.7.1.10 and 50.7.2.4) P. Proactive transfer of information supporting referrals (50.7.1.10 and 50.7.2.4) Q. Support Kentucky’s Quality Health Initiative through integration (50.7.1.1) R. Supply data to Kentucky’s Data Analytics initiatives (50.7.2.13)

50.7.1 Functional Requirements 50.7.1.1 Quality Health Information (QHI)

CHFS has developed a technological roadmap for the Kentucky QHI framework. The QHI facilitates the implementation of technology standards and approaches for the development of an interoperable, scalable, and easily adaptable cross-sector technology framework. CHFS legacy systems, including the KY Medicaid Management Information Systems KYMMIS, were implemented on independent platforms creating individual monolithic architectures. Communication between systems is difficult as is aggregation and correlation of data in the enterprise. CHFS has adopted the QHI framework to promote interoperability, reusability, and sharing of information throughout the enterprise as well as across organizational boundaries. Systems proposed with this RFP shall be compliant with the QHI framework as identified in the sections below. This QHI framework is required for all applications hosted within the Commonwealth. Commonwealth prefers use of the tools identified within the QHI Framework for the DDI components of this RFP however, this is not required. The Commonwealth requires the Authorized User of an active, signed KHIE Participant using the web based solution to use Kentucky Online Gateway (KOG) as well as requires the solution to remain compatible and interoperable with all other QHI components. There is no licensing requirement for KOG; however, all other tools will require the vendor to provide licenses specifically for the solution. Vendors will be responsible for all costs associated with interfaces as well as for any licenses required for the KHIE solution.

QHI Components – Portals

A. Citizen Portal: The CHFS Citizen Portal provides access via single sign-on to view information including eligibility, enrollment status, MCO encounters, and claims for benefits received from the CHFS. In addition, it should also be a vehicle to view personal health records through the Kentucky Health Information Exchange (KHIE). The new KHIE solution shall interface in real time to the CHFS Citizen Portal to collect or distribute information to and from citizens. The Vendor is responsible for the interface between the solution and the Citizen Portal.

B. Partner Portal:

67

The CHFS Partner Portal, currently being developed by CHFS, provides access via single sign-on for provider enrollment, disenrollment, information inquiry, information management, communication, grievance and appeals, and outreach. The KHIE solution shall be responsible for providing a portal for use by participants. The Providers will be accessing the KHIE Provider Portal via the CHFS Partner Portal through redirection. The navigation between the KHIE solution and the Commonwealth’s Partner Portal must be transparent and seamless with no additional logins.

C. Worker Portal:

QHI contains a centralized worker portal however the KHIE solution will not be required to utilize it. The KHIE Vendor shall provide a KHIE Worker Portal within the solution for all functions to be performed by Commonwealth staff.

D. Single Sign On and Security Framework All portals shall provide role based access, and will integrate with KOG. KOG will provide identity proofing, approval workflow, user store, and single sign-on support services. All portals shall integrate with KOG for both user provisioning and single sign-on purposes. For user provisioning, the Vendor shall provide role information so that KOG can be configured. For single sign-on, all portals shall implement a federated security model based on WS-Federation and SAML.

QHI Components – Tools

E. Business Rules Engine (BRE): Kentucky has implemented Corticon’s Business Rule Engine (BRE) to execute and maintain complex business rules. The new KHIE solution shall utilize a business rules engine; however, it is not required to utilize the KY solution.

F. Enterprise Service Bus (ESB):

Kentucky has implemented ESB using Microsoft BizTalk Server 2010 with its toolkit 2.1 to provide a framework for integration of services. The Vendor’s ESB is required to be compatible and interoperable with the Commonwealth’s ESB.

G. Security Framework:

The Kentucky Online Gateway (KOG) (maintained by the Commonwealth) provides user provisioning and authorization services. The new KHIE solution shall utilize the KOG solution for user provisioning and authorization services. KHIE shall interface with KOG through Active Directory Federation Services (ADFS) for SSO (Single Sign-On). The solution shall be ADFS/WS Federation/Security Assertion Mark-Up Language (SAML) 2.0 compliant and use Claims for Authentication and Authorization. KOG supports both active (WS-Trust) and Passive (WS-Federation and SAML 2.0) scenarios. KHIE shall

68

invoke KOG services prior to executing a user request from within the KHIE solution. The Vendor is responsible for the interface between the KHIE solution and the KOG.

H. Master Data Management (MDM):

Kentucky has implemented IBM’s Infosphere MDM (standard edition) for suites of MDM services. The main purpose of MDM is to manage an Enterprise Master Person Index for KY citizens and Master Provider Index for KY providers. The KHIE solution shall include its own eMPI and will be required to register entities with the KY MDM solution. The Vendor is responsible for the interface between the KHIE solution and the MDM.

Other QHI Components

I. Kentucky Medicaid Management Information System (KYMMIS): The KYMMIS is the current claims processing and retrieval system. The KYMMIS is hosted and maintained by Hewlett Packard Enterprise Services (HPES). KYMMIS is a customized HP interchange system. It supports both FFS reimbursement as well as Managed Care programs. The system is currently in the process of being replaced with Kentucky Medicaid Enterprise Management System (KYMEMS). The KHIE solution will receive healthcare claims and other data from the KYMMIS system and those interfaces are currently non-standard, flat files. The KHIE solution will be compatible with the legacy feeds. In addition, the Vendor will be required to change that interface to the new MEMS once it is in place. At that time, new requirements will be determined in JAD sessions. The KHIE Vendor shall participate in these sessions and complete the appropriate changes based on the timeline established in the MEMs project.

J. Health Benefit Exchange (HBE):

The Commonwealth of Kentucky has developed a HBE which is comprised of a closely integrated Eligibility and Enrollment (E&E) solution as well as a Plan Maintenance and Billing (PMB) solution. The HBE Vendor has implemented a custom E&E solution and PMB solution. The core E&E system was developed using Microsoft technologies. The E&E and PMB are hosted at the Commonwealth’s data center. E&E is an end-to-end solution that includes functions required to process eligibility and enrollment for all Income Eligible Medicaid members and other health insurance affordability programs offered on the HBE. It also supports functions such as workflow, Notifications, Scheduling, Document Management System, Business Rules Management, and associated business processes required to launch and continuously operate an efficient and effective E&E System. A PMB solution includes functions required to offer and maintain individual and group insurance products including Qualified Health Plan (QHP) Certification, Premium Billing, Collections & Reconciliation, Enrollment Maintenance, and more, required to offer individual and group health insurance products on the HBE and both

69

support and sustain its seamless operation. The KHBE solution has been expanded to include functions for Non-Income Eligible Medicaid, SNAP and TANF in February 2016 to replace the legacy KAMES system. The new KHIE solution shall interface with the HBE solution for all Medicaid eligibility information.

K. Public Health Systems The mission of the Department for Public Health (DPH) is to promote and protect the health and safety of Kentuckians. DPH provides policy and program governance for systems supporting local health departments, communicable disease control, disease and injury surveillance, enforcement of public health regulations, public health education, risk identification and reduction, policy development, and responses to disasters.

L. Immunization Registry Integration

The new KHIE solution shall support direct pass-through of immunization updates, history queries and query responses as defined in the Center for Disease Control HL7 2.5.1 Implementation Guide for Immunization Messaging. In addition it shall support Query By Parameter (QBP) as specified by the Commonwealth during JAD sessions in order that the result is included in KHIE query results.

M. NEDSS Integration

DPH operates a local instance of the CDC sponsored NEDSS based system. This system is used by epidemiologists and health officials to manage reportable disease information. The KHIE receives lab result feeds from laboratories and providers via EHRs and filters them for reportable conditions. It then forwards these results to NEDSS using PHIN-MS. The new KHIE solution shall continue to provide and support this functionality as specified by the Commonwealth. For all operations where the KHIE is performing creation or transformation of message streams that fall under Meaningful Use requirements of the EHR Incentive Payment Program for participating providers. The new KHIE solution shall be Office of the National Coordinator’s Authorized Testing and Certification Body (ONC-ATCB) 2014 certified. In addition, the Vendor shall maintain the latest ONC-ATCB certification throughout the life of this contract, to ensure Meaningful Use Stage 3 and future objectives will be addressed.

N. Cancer Registry Integration

The Kentucky Cancer Registry is operated by the University of Kentucky under the direction of DPH. Providers are able to submit various documents and messages to the Cancer Registry via their KHIE connection. The new KHIE solution shall continue to provide and support this function as specified by the Commonwealth and cancer registry.

O. State Lab Integration

70

The Kentucky State Lab performs many important procedures for providers across the state. The KHIE receives lab result data from the State Lab and includes it in its repository. This data is included in clinical documents. The new KHIE solution shall continue to provide and support this functionality as specified by the Commonwealth. The State Lab feed contains lab result messages only. There is no patient identity feed provided. Therefore, the new system must be capable of performing patient registration directly from the information contained in the lab result message. Currently, this is simply taken from the PID segment of the lab result message.

P. Biosense and Syndromic Surveillance

The KHIE currently receives ADT messages from provider EHR systems for patient demographics and clinical data. The system detects which of these messages meet the conditions for reporting to Biosense and creates a message meeting Biosense specifications and forwards it to Biosense. The new KHIE solution shall continue to provide and support this functionality as specified by the Commonwealth. For all operations where the KHIE is performing creation or transformation of message streams that fall under Meaningful Use requirements of the EHR Incentive Payment Program for participating providers, the new KHIE solution shall be Office of the National Coordinator’s Authorized Testing and Certification Body (ONC-ATCB) 2014 certified. In addition, the Vendor shall maintain the latest ONC-ATCB certification throughout the life of this contract, to ensure Meaningful Use Stage 3 and future objectives will be addressed.

Q. All Payer Claims Database (APCD):

Following Kentucky’s implementation of American Recovery and Reinvestment Act (ARRA), Health Information Technology for Economic and Clinical Health (HITECH), Affordable Care Act (ACA) health care reform and Health Information Technology (HIT) stimulus initiatives, the Commonwealth is implementing an APCD. Access to timely, accurate data is fundamental to improving quality, mitigating costs, and promoting transparency in the health care delivery system. The new KHIE solution shall support the functions required to consume claims and encounter data from the APCD solution.

R. Electronic Medical Record (EMR) Interfaces:

Kentucky’s vision is to build a foundation for connectivity for all EMRs to facilitate the exchange of health information between exchange participants. The QHI foundation should provide this connectivity to exchange information with the KHIE using web services or the ESB. The QHI foundation should enable EMR Vendors to incorporate into the physicians practice workflow access to all applicable KY State applications and reporting services. For example, a physician could retrieve a report directly from the State’s Prescription Monitoring Program system through EMR interface without

71

leaving his/her EMR. The new KHIE solution shall provide the capability to keep data separated according to source so that each submitter’s data can be delineated from all other submitters’ data. The technique employed may be physical or logical.

50.7.1.2 MITA and the Seven Conditions and Standards for Enhanced Federal

Funding The Medicaid Information Technology Architecture (MITA) defines Information, Technical and Business architectures and Capability Matrices to evaluate those architectures. The Seven Conditions and Standards (Modularity, MITA, Industry Standards, Leverage, Business Results, Reporting, and Interoperability) define the requirements that systems must meet in order to qualify for enhanced funding from CMS. The Commonwealth requires that these conditions be met to the extent that they apply to an HIE system. Specifically, the HIE should meet all of the Seven Conditions and Standards, including the MITA condition which simply requires alignment and increasing maturing with MITA. Most of the Business Architecture does not apply as it is specific to Medicaid. However, the Care Management portion of MITA and the Information and Technical Architectural concepts do apply and are required.

50.7.1.3 Service Oriented Architecture (SOA)

The goal of the Commonwealth is to develop consumer-centric systems to provide the best services to the members of Kentucky combining efforts to streamline workflow, leverage all types of resources, and achieve economies of scale. The Commonwealth envisions a system that is adaptable, expandable, and flexible using the QHI architectural components wherever possible. To this end, the new KHIE solution shall be capable of hosting and consuming web services with external systems. In addition, the solution shall implement the KOG security model as discussed in QHI Security Framework described in this RFP. The Commonwealth also desires to include portions of whole running applications in workflow orchestrations. The new KHIE solution shall provide the ability to receive a redirected user and return them to the system from which they came without the user experience being interrupted. Specifically, the new KHIE solution shall be capable of receiving two URLs: one for a successful operation and one for a failed operation either during the redirect or prior to it, and redirecting the user back to the appropriate URL.

50.7.1.4 Provider Onboarding “Provider Onboarding” refers to the process of connecting provider and hospital EHR systems to the KHIE. It begins after the participation agreement has been signed and ends when the feeds are successfully tested and established in Production. The Commonwealth’s goal is to reduce the time required to accomplish this process. This is one of the primary strategic goals of this

72

procurement. The successful bidder will pay close attention to this section and will propose a mature and complete approach to solving this problem.

A. General Onboarding Requirements The Vendor shall actively manage the provider onboarding process including project management and technical support. The Vendor shall demonstrate an ongoing strategic and tactical program to reduce the time it takes to onboard providers.

B. Onboarding Test Requirements

The Vendor shall provide a testing methodology that provides maximum convenience for the systems connecting to the Kentucky Health Information Exchange (KHIE) without compromising security or data integrity. Systems that provide self-service testing features will be preferred. Systems that provide message testing in the production environment will be allowed so long as there is a solid mechanism for keeping test messages out of the production data set. The successful bidder will propose a comprehensive testing approach that spares work and time for the EHR technical team as well as the Commonwealth staff. The new KHIE shall implement both positive and negative acknowledgements to inbound messages and shall process all acknowledgements provided by other systems in response to outbound messages. Acknowledgements may be synchronous or asynchronous depending on the use case. The new KHIE system shall be fully capable of acknowledgement processing both as sender and receiver, and in both synchronous and asynchronous modes.

C. Testing with EHRs

The Vendor shall test with clinical systems to ensure compliance with standards and specifications pertaining to message and document format and vocabulary. In some cases, it may be necessary to map vocabularies or translate messages. While KHIE is committed to standards, it is also committed to exchanging meaningful clinical information. The new KHIE solution shall have the ability to translate messages to and from applicable standards or versions of standards. This feature shall be configurable separately for each feed. In addition, the solution shall be capable of vocabulary mapping of individual feeds. The Vendor shall ensure that all relevant testing has been successfully accomplished prior to allowing production messages to be submitted. The Vendor shall provide access to all messages for testing verification through testing tools which allow the vendor staff and KHIE staff extended visibility into the message components and which provide plain English error information pinpointing bad data problems.

73

50.7.1.5 Help Desk The Vendor shall implement and operate help desk services during normal KHIE business hours for all KHIE participants. This shall include the following: 1. Staffing 2. Call center function including toll-free line 3. Web-based ticket tracking system 4. Call center performance reporting

50.7.1.6 KHIE Administrative Functions A. Capabilities

The Vendor shall implement an online portal which shall include the following administration functions, at a minimum, for the management of the system: 1. The proposed system shall have the ability to track messages from source to

destination including measurements of latency at salient processing events such as receipt, validation, and final disposition or delivery.

2. The proposed system shall have the ability to view message content in data feeds other than Direct.

3. The proposed system shall have the ability to easily and flexibly search for all data present in the eMPI system.

4. The proposed system shall have the ability to perform data stewardship activities.

5. The proposed system shall have the ability to view all pertinent configuration settings including the rule base.

6. The proposed system shall have the ability to view the matching rule or rules that resulted in the matching of individual records. This needs to be efficient and associated to the patient and not multiple screen to find this info. For example, the capability should allow a right click on a patient to then get the matching criteria and history.

7. The proposed system shall have the ability to view any and all data translation maps existing within the system and their associated feeds.

8. The proposed system shall have the ability to view reports regarding the system operation, health, performance, usage.

9. The proposed system shall be able to ID feed problems based on severity (e.g. not every problem is a big problem;

10. The proposed system shall have a dashboard for viewing connections (external registries, like Biosense, etc.)

B. Integration with KOG The Worker portal shall integrate with the Kentucky Online Gateway for user provisioning and single sign-on. This is covered in further detail in the Quality Health Information section under the subheading “Security Framework”.

50.7.1.7 KHIE Provider Portal

The Vendor shall implement an online portal accessible by the participant community for the purpose of interacting with the system and the KHIE staff. Additionally, the KHIE Provider Portal shall integrate with the Kentucky Online

74

Gateway for user provisioning and single sign-on and shall adhere to the Security Framework. The portal shall include all features necessary for providers and KHIE staff or designees to efficiently manage all administrative functions including but not limited to the following:

A. Provider Directory Maintenance: Providers, especially hospitals and large practices, need the ability to update the KHIE Provider Directory with their information as providers join and leave the establishment. Currently, this is performed by KHIE staff from spreadsheets provided by the participant organization. This should be an automated, self-service process that is configurable and uses validation controls. B. Online Interface for Direct: Providers unable to integrate with Direct will need an online feature for this purpose. Access to the Provider Directory and easy to use message compilation tools are required. The user shall be able to easily gather clinical data from the system and send it to a Direct address selected from the directory. C. Access to Clinical Data: Providers lacking an EHR system need a place where they can view the data in the clinical data repository, the XDS.b document repository, and the Immunization Registry. The new KHIE solution shall provide these functions through a read-only community health record system. D. Systems Management: Clinical systems integrating with KHIE are managed by technical staff representing the provider. These new KHIE solution shall provide implementers a window into the status of the feeds they are providing and the services they are consuming. E. Integration with KOG: The KHIE Provider Portal shall integrate with the Kentucky Online Gateway for user provisioning and single sign-on. This is covered in further detail in the Quality Health Information section under the subheading “Security Framework”.

50.7.1.8 Electronic Master Patient Index (eMPI)

Currently, there are multiple MPIs within the KHIE system and it is difficult to keep them synchronized. KHIE greatly wants to simplify this architecture to a single eMPI/RLS instance. The successful bidder will demonstrate a mature solution to this problem. A. The Vendor shall implement an electronic Master Patient Index (eMPI)

capable of matching patient and business demographic records having variable data based on configurable rules.

B. The eMPI shall have the ability to register identities with the CHFS master MDM implementation, which is an IBM MDM product implementation.

C. The eMPI or Worker Portal shall provide a set of screens and an efficient workflow process to support the work of Data Stewards charged with making decisions about near matches, validation of inputs and other data related issues.

75

D. The eMPI shall provide rule based matching algorithms that follow industry standards which can be adjusted as necessary by KHIE data steward staff working together closely with vendor.

E. The eMPI shall provide a function for handling alias, baby names, and pseudo-entries.

F. The eMPI shall allow administrative data integrity staff to delete identities which were temporary or made in error such as test.

50.7.1.9 Public Health Gateway

For all operations where the KHIE is performing creation or transformation of message streams that fall under Meaningful Use requirements of the EHR Incentive Payment Program for participating providers, the new KHIE solution shall be Office of the National Coordinator’s Authorized Testing and Certification Body (ONC-ATCB) 2014 certified. In addition, the Vendor shall maintain the latest ONC-ATCB certification throughout the life of this contract, to ensure Meaningful Use Stage 3 and future objectives will be addressed.

A. The new KHIE solution shall allow for a provider's EHR to submit messages to the Kentucky Cancer Registry and the Kentucky Immunization Registry using the HIE as a pass-thru entity.

B. The new KHIE solution shall allow for a provider's EHR to submit Syndromic Surveillance messages to the CDC’s Biosense system using the HIE as a pass-thru entity. Additionally, the system shall be capable of performing the function on behalf of providers working from submitted admission/discharge/transfer (ADT) messages.

C. The new KHIE solution shall support the receipt of all laboratory results including those for the purpose of ELR of reportable diseases and conditions. These messages shall be validated according to Kentucky Department for Public Health specifications and filtered for reportable conditions which are forwarded to NEDSS. Specially protected information shall be flagged for protected inclusion in the CDR or omitted until that functionality is supported and successfully implemented.

D. The new KHIE solution shall be able to export data to the Kentucky Health Data Trust by way of a real time data feed or a batch file notification.

50.7.1.10 Directed Exchange

A. The Vendor shall implement a peer to peer messaging system following the Direct specification. This includes a provider directory and full HISP services.

B. The Vendor shall implement an online portal for the use of Direct C. The Vendor shall implement system interfaces with provider EHR systems in

support of Direct D. The new KHIE solution shall be DTAAP Certified.

50.7.1.11 Query-Based Exchange

The Vendor shall implement a query-based exchange feature that accepts clinical system data and healthcare claims feeds as inputs and creates clinical

76

documents and data sets on demand from all sources including, real-time access of the immunization registry. A. Inputs include, at a minimum:

1. HL7 feeds from clinical systems such as provider EHRs and hospital information systems.

2. Patient demographics feeds from the Commonwealth’s immunization registry.

3. Real-time access of the immunization history from the Commonwealth’s immunization registry.

4. Medicaid member feeds from the Commonwealth’s Health Benefit Exchange.

5. Medicaid claims feeds from the Medicaid Fiscal Agent, Pharmacy Benefits Manager (PBM), and multiple Managed Care Organizations (MCO). Claim types include Medical, Institutional, Pharmacy and Dental.

B. Outputs include, at a minimum: 1. An on-demand C-CDA document that integrates, de-duplicates and filters

data from multiple clinical and claims sources. This document shall be registered in the XDS.b Registry as an “on demand” document.

2. Immunization history response (RSP) to immunization history request (QBP).

50.7.2 Technical Requirements 50.7.2.1 Portals

The existing KHIE solution includes a community health record system (currently called VHR) that providers can use to access clinical information. This community health record is read only with respect to clinical information. It provides access to data stored in the clinical data repository from all sources. It also provides access to documents stored in the XDS.b facility. The new KHIE solution shall continue to provide this function. The existing KHIE solution does not provide a worker portal for KHIE staff to administer, monitor and control the system. There is a collection of functions, but they are separate and it is difficult if not impossible to determine a holistic state of an operation. Solving this problem is one of the primary strategic aims of this procurement. The successful bidder will demonstrate a mature approach to placing system monitoring and control functions within convenient reach of the Commonwealth staff.

A. Standards All portals shall implement the following standards at a minimum:

1. WS-Federation 2. WS-Trust 3. SAML 2.0 4. SSL/TLS

77

B. Security All portals shall provide role based access, and will integrate with KOG. KOG will provide identity proofing, approval workflow, user store, and single sign-on support services. All portals shall integrate with KOG for both user provisioning and single sign-on purposes. For user provisioning, the Vendor shall provide role information so that KOG can be configured. For single sign-on, all portals shall implement a federated security model based on SAML. C. Performance Response time for all portal functions (except complex reports) shall not exceed eleven (11) seconds at any time with an average response time of three (3) seconds or less. D. Branding All Portals shall be branded according to Commonwealth specifications, which are subject to change. The solution shall be flexible enough in this regard to be capable of changing basic branding with 48 hours’ notice. E. Workflow All portals shall provide a solution for integrating with CHFS portals in a way that provides a transparent user experience. This includes being capable of defining configurable workflows within the application, and participating in workflows defined by external workflow engines as may be deployed by the Commonwealth. The Commonwealth standard for workflow engines is K2 Blackpearl. F. Availability All portals shall be available 24X7X365 with the exception of approved maintenance windows.

50.7.2.2 Electronic Master Patient Index (eMPI) The Vendor shall implement a single eMPI/RLS to serve the entire HIE. The eMPI shall be accessible via various standards as necessary to serve this purpose. The new KHIE solution shall have the ability to provide extra protection based on a Very Important Person (VIP) indicator that is present in the eMPI (see also 50.7.2.6). In addition this indicator must be able to be set either manually or from an incoming message. A. Integration with the CHFS Master Data Management System The new KHIE solution shall implement its own dedicated eMPI. This eMPI shall be capable of registering parties with the CHFS MDM master instance, which is IBM’s MDM product included with Infosphere. B. Matching Behavior

1. Records shall be matched and linked rather than merged together with only one surviving record

2. Records shall be matched according to a configurable rule base

78

3. The new KHIE solution shall retain the rule or rules that resulted in a match

4. An update to a record shall cause the system to re-evaluate that record’s current linkage.

C. Query Behavior 1. Search criteria shall find any matching record in a group of linked records. 2. Data returned should be flexible in its contents, format and completeness.

This means that multiple output formats are expected, and in some cases the completeness may vary. For example, one case may call for returning the multiple occurrences of values existing in a group of linked records. The middle name might be different or some other field might vary from one record to the next within a group of linked records. Systems featuring this flexibility are preferred, but not required.

D. System Administration 1. The eMPI rule base shall be available to the Commonwealth staff in a

convenient format 2. The eMPI system shall provide a way to manage and assign work to

individual KHIE Worker Portal employees 3. The eMPI system or the Worker Portal shall implement an administrative

user interface sufficient to meet the needs of the Commonwealth staff in their efforts to monitor and control the system. It is preferred that this take place in the Worker Portal unless the eMPI is the IBM MDM product, in which case the Commonwealth is already familiar with these functions.

4. The eMPI system or the Worker Portal shall implement a user interface for Data Stewards to expedite near matches and perform other Data Steward functions such as failed messages. It is preferred that this take place in the Worker Portal unless the eMPI is the IBM MDM product, in which case the Commonwealth is already familiar with these functions.

E. Standards The Commonwealth desires a single eMPI system that is accessible via various applicable standards such as PIX/PDQ, XDS.b, HL7 ADT and XCA/XCPD. The preferred solution would not require replication of data to various systems and would instead allow a single underlying engine to be used for all of these purposes.

50.7.2.3 Public Health Gateway For all operations where the KHIE is performing creation or transformation of message streams that fall under Meaningful Use requirements of the EHR Incentive Payment Program for participating providers, the system shall be Office of the National Coordinator’s Authorized Testing and Certification Body (ONC-ATCB) 2014 certified. In addition, the Vendor shall maintain the latest ONC-ATCB certification throughout the life of this contract, to ensure Meaningful Use Stage 3 and future objectives will be addressed. A. Immunization Registry The new KHIE solution shall support direct pass-through of immunization updates, history queries and query responses as defined in the Center for

79

Disease Control HL7 2.3.1 and above Implementation Guide for Immunization Messaging. In addition it shall support KHIE querying the IR utilizing Query By Parameter (QBP) as specified by the Commonwealth during JAD sessions in order that the result is included in KHIE query result to providers. B. NEDSS

1. The new KHIE solution shall receive lab result HL7 messages from lab and provider systems, determine what is reportable to NEDSS according to DPH specifications, and output an appropriate message to be consumed by NEDSS.

2. Communication with NEDSS shall be via PHIN-MS and shall follow industry standards for Electronic Laboratory Reporting.

C. Cancer Registry The Kentucky Cancer Registry receives reports from providers about cancer patients. These reports are submitted via the KHIE and passed directly through to the CR with no additional processing beyond logging and auditing. The new KHIE solution shall continue to support this functionality as well as storing the messages within KHIE data store.

50.7.2.4 Directed Exchange A. The new KHIE solution shall have a Provider Directory that is accessible from

the KHIE Provider Portal. The Provider Directory shall have, at a minimum, the following features: 1. The new KHIE solution shall be capable of exporting the Provider

Directory in whole or in part in a format to be determined during JAD sessions. Standard formats are preferred.

2. A self-service portal for providers to request Direct addresses for the transmission of messages and clinical documents.

3. Role based access for providers and KHIE staff to submit new provider information or edit existing provider information.

4. Store user populated provider information with or for corresponding Direct addresses.

5. The ability to search for and capture User populated provider information and corresponding Direct addresses.

6. The ability to replace external user generated information through a batch upload process.

B. The new KHIE solution shall provide the ability to forward information, such as the C-CDA, from the community health record, currently called the VHR, to a Direct address.

C. The new KHIE solution shall afford KHIE the ability to provide HISP services to Clinical Systems who are XDR enabled and HISP agnostic. Additionally, the system shall be able to report separately the messages that have XDR to SMTP translation.

D. The new KHIE solution shall be configured such that a provider may send a message, clinical data or other information to the patient’s Personal Health Record (PHR) using their existing connection to KHIE.

E. The Vendor shall implement Direct messaging by providing: 1. Access to a portal which provides users’ access to the DSM/HISP.

80

2. Provide connection of Direct enabled EHRs to the HISP via Direct (SMTP), Direct + XDR/XDM and SOAP + XDR/XDM.

3. Provide unlimited in-state Provider Portal Direct address licenses or mailboxes.

4. A configurable mailbox capacity maximum initially set to 10GB per address. Should include mailbox management notification when size limit is being reached and also when exceeded.

5. Ability to set-up multiple addresses based on user & functions. 6. Ability to create messages and attach supporting external information

(Continuity of Care Documents (“CCD”), Adobe PDF Documents (“PDF”) (etc.) from an external file source.

7. Ability to search and select one or more message recipients from the Provider Directory.

8. Ability to receive messages from other Direct users and external sources. 9. Ability to view message content and corresponding attached information. 10. Ability to detach and save attached content. 11. Train-the-trainer and subject matter expertise for the “Solution” integration

efforts for all core platform integration areas. 12. The vendor, in conjunction with Commonwealth, shall participate in the

creation of initial training materials to support on-boarding efforts. 13. Product support for issues related to the “Solution”. 14. HISP to HISP connections including external HISPs that have not

completed the Direct Trusted Agent Accreditation Program. 15. Connections to DTAAP approved HISPs will automatically be connected

through Direct Trust Org’s distribution of Trust Bundles. 16. Securely transmits messages to health message receivers or external

HISPs depending on the Direct address. 17. Securely receives messages from authorized health message sources

and external HISPs. 18. Securely receives and decrypts messages from health message sources. 19. Encrypts messages and securely transmits them to health message

receivers. 20. Manages trust certificates used to encrypt and decrypt messages per

Direct standards. 21. Activity and audit reports to be created and published. The Solution never

automatically deletes logs. The logs may be deleted from the Solution manually by mutual agreement.

50.7.2.5 Query-Based Exchange/Community Health Record

A. The existing system allows provider systems to submit a QRY^T12 message to the KHIE via a web service and receive back a DOC^T12 containing a C-CDA document created on demand from underlying clinical and claims based data (not documents). The web service utilizes the WS-Security standard encrypting the message content and then using an unsecure HTTP transport. The new KHIE solution must continue to support this function until existing participants can be migrated to a new solution.

81

B. The new KHIE solution shall provide pass-through query capabilities to the Kentucky Immunization Registry from EHR systems.

50.7.2.6 Privacy and Security

A. The new KHIE solution shall provide privacy and security components that follow national standards and meets all HIPAA security and privacy requirements. HIPAA Compliance: This RFP will require adherence to HIPAA. It is the Offeror responsibility to clarify its status with regard to HIPAA with CHFS. The Offeror shall agree to use and disclose Protected Health Information in compliance with the Standards for Privacy of Individually Identifiable Health Information (“Privacy Rule”) (45 C.F.R. Parts 160 and 164) under the Health Insurance Portability and Accountability Act of 1996. The Offeror shall ensure that all Offeror actions are compliant with HIPAA rules for access, authentications, storage and auditing, and transmittal of electronic personal health information (e-PHI). Where applicable, the Offeror shall establish and maintain HIPAA compliant controls and procedures that protect, define, and limit circumstances for access, use, and disclosure of personal health information (PHI). The Offeror shall not be permitted to use or disclose health information for any reason other than what is mandated within this contract

B. The new KHIE solution shall provide privacy and security components that follow Kentucky state-specific laws and regulations including the capability to support the patient’s desire to opt out of having their personal health information viewed by providers through the query based exchange functionality.

C. The system hardware/infrastructure recommendations shall meet national security guidelines. For cloud-based proposals, please submit information about the hosting vendor’s security plan.

D. The new KHIE solution shall be covered under the Vendor’s Business Continuity and Disaster Recovery plan.

E. The new KHIE solution shall support role-based access. F. The new KHIE solution shall support object-based user authorization profiles. G. The new KHIE solution shall support task-based user authorization profiles. H. The new KHIE solution shall have the ability to provide audit log reporting

features. I. The new KHIE solution shall have the ability to produce an accounting of

disclosures audit trail reporting that can be used to identify transactions or data accesses that have been performed. Initially this ability may be manual and directly or indirectly available to KHIE staff to obtain results, by patient or by user, formatted as a human readable report to be sent or printed. The audit should be flexible enough to audit for a specific patient or for a specific user and should be retained for six years according to HIPAA or any other applicable regulation.

J. The new KHIE solution, once final implementationis complete, must have the ability for the accounting of disclosures audit trail to be obtained through a

82

flexible, on-demand query and reporting function using the KHIE Worker Portal. It will be available to KHIE staff to identify transaction or data accesses that have been performed ad hoc, by specific patient or by specific user, formatted as a human readable report to be sent or printed. The audit information shall be retained for a minimum of six years according to HIPAA or any other applicable regulation.

K. The new KHIE solution shall log all unsuccessful logons and lock out users after a certain number of unsuccessful attempts as configured by the customer.

L. The new KHIE solution shall provide a global log out feature that destroys the SAML token either directly or redirection to KOG.

M. The new KHIE solution shall support WS-Federation and SAML. N. The new KHIE solution shall provide detailed logging of all data access and

provide convenient access of this log by way of both online and by standard reporting means.

O. The new KHIE solution shall provide different levels of access based on user role, site, and/or enterprise settings.

P. The new KHIE solution shall have the ability to provide extra protection based on a VIP indicator that is present in the eMPI. An optional second notice should be available to remind the user that they’ve chosen a VIP record.

Q. The new KHIE solution shall provide for access to VIP records by role designated in the user account.

R. The new KHIE solution shall permit the security administrator to set events that are considered security violations as well as provide real-time notification of any violations.

S. The new KHIE solution shall provide termination of user sessions/connections by an administrator if a breach is suspected.

T. The new KHIE solution shall have the ability to configure individual user interface components to exhibit the appropriate behavior based on the user’s roles.

U. The new KHIE solution shall have the ability to identify all users who have accessed (including viewing, printing, and modifying/entry) an individual’s health information over a given time period, including date and time of access.

V. The new KHIE solution shall support electronic signatures where appropriate using accepted and evolving industry standards.

W. The new KHIE solution shall be able to identify certain information as confidential and only make that accessible by appropriately authorized users.

X. In order to comply with 42 CFR Part 2, the new KHIE solution shall be able to identify specially protected health information such as behavioral health information and handle such information in accordance with 42 CFR Part 2.

Y. The new KHIE solution shall support protection of confidentiality of all Protected Health Information (PHI) in transit and at rest in accordance with HIPAA and HITECH.

83

Z. The data center where the solution is hosted shall be either NIST 800-53 current revision or Federal Risk and Authorization Management Program (FedRAMP) certified.

AA. The new KHIE solution shall support Web services access utilizing SOAP and SSL\TLS.

BB. The new KHIE solution shall secure the patient's data at all times and in all modules of the product (e.g. encrypted at rest, data encrypted in motion, data on handheld devices).

CC. The new KHIE solution shall have the ability to provide audit logs/error logs to detect unauthorized access or activity, and automatically and proactively report to the Commonwealth Security Staff.

DD. The new KHIE solution shall support the ATNA (Audit Trail and Node Authentication) profile and TLS (Transport Layer Security).

50.7.2.7 Infrastructure

A. The new KHIE solution shall conduct routine backup procedures without the users having to be off the system.

B. The new KHIE solution shall have the ability to support a variety of point of care and input devices such as, hand held/portable, laptops, and tablets.

C. The new KHIE solution shall have the ability to provide common reporting functionality which will satisfy all basic or fundamental reporting requirements.

D. The vendor shall provide load testing tools and load testing as part of their implementation.

E. The new KHIE solution shall be scalable to accommodate additional utilization, users, transactions and/or additional local/remote sites.

F. The new KHIE solution shall support multiple environments including development, test, QA, training and production.

G. The new KHIE solution shall provide an alerting and monitoring utility. H. The system application shall expose data via secure Web Services, VPN,

SFTP, and other secure protocol. I. The new KHIE solution shall maintain Infrastructure standards certification of

ISO/IEC 27002. J. The new KHIE solution shall have the capability to be securely accessed from

any location with an internet/broadband connection and is compatible with current leading web browsers such as IE, Chrome, Firefox, and Safari.

K. Upon system turnover all information shall be made available to the successful bidder in XML, X-12, HL7, CSV, or comma delimited text or other means as mutually agreed upon by the vendors and the Commonwealth.

L. The new KHIE solution shall support and implement redundancy/fault tolerance for system availability.

M. The new KHIE solution shall provide on-line help screens to assist novice users in all applications.

N. The new KHIE solution shall support the following document types: 1. CCD 2. C-CDA 3. CDA

84

4. Any future HL7 document standards O. The new KHIE solution shall support a variety of data exchange standards

including but not limited to: 1. HL7 messages 2. Healthcare Medical and Pharmacy claims 3. Dental claims 4. Vision claims 5. HL7 Clinical Documents such as C-CDA 6. IHE profiles 7. NEMSIS run sheets

P. The new KHIE solution shall provide a method for archiving patient health information, and all supporting electronic files (including application software files).

Q. The new KHIE solution shall support multiple communication channels for sending messages to providers. At a minimum this shall include sending messages to Direct addresses, the KHIE Provider Portal, and directly to provider clinical systems.

R. The systems patient matching logic shall allow for customizations which would be unique to KHIE if desired. This must be explained and demonstrated.

S. The new KHIE solution shall have the ability to provide common reporting tools and analytics that are compatible with recognized, industry standard reporting tools such as Business Objects, Cognos, Microsoft SSRS, etc.

50.7.2.8 Interoperability A. The new KHIE solution shall support standard HL7 interfaces. B. The new KHIE solution shall interface with legacy and departmental systems. C. The new KHIE solution shall provide the ability to filter incoming data feeds to

strip specially protected health information. D. The new KHIE solution shall allow users to view a display of archived

transactions and audit file as well as the transactions as they are being processed.

E. The new KHIE solution shall be able to support the ability of providers to send HL7 messages using Minimal Low Level Protocol (MLLP) over Virtual Private Network (VPN); hence, it shall support VPN connectivity. Additionally, the system shall support standard web service connectivity for HL7 and IHE profiles.

F. The new KHIE solution shall provide its own eMPI, which can be any technology of the implementer’s choice so long as it is capable of registering entities with the Commonwealth's Master Data Management (MDM) solution, which is IBM's MDM product.

G. The new KHIE solution shall support industry standards. H. The new KHIE solution shall include flexible features such as user-defined

fields that enable the KHIE designated user to build tables for the translation of data.

85

I. The new KHIE solution shall have the ability to interface via HL7 compatible interface for receiving ADT information.

J. The new KHIE solution shall have the ability to account for and log any records that were merged and unmerged based on algorithms. This information shall be made available to the KHIE staff on a routine report.

K. The new KHIE solution shall receive feeds of claims data from various MCO's, the APCD and the Commonwealth's Medicaid Fiscal Agent. The solution shall change the format of the data from administrative to clinical, summarize, and then filter. The solution shall parse and filter as deemed appropriate by the Commonwealth the claims data into the CDR in order to share it through the KHIE Provider Portal and IHE documents. Data will be provided daily through file exchange or, in some cases, in real-time by way of web services. Claims can be reversed or adjusted requiring HIE to process updates. The solution shall process these updates as they are received and in the order in which they occurred on the source system. The Commonwealth will provide a means by which this order can be determined.

L. The new KHIE solution shall support configurable workflow. M. The new KHIE solution shall incorporate extensive, secure

telecommunications capabilities that link staff and clinicians from remote locations to the central site.

50.7.2.9 Performance and Reliability A. The online transactions shall average below three (3) seconds or less

response time for all non-reporting functions. The response time for all non-reporting functions shall not exceed eleven (11) seconds at any time.

B. The new KHIE solution shall have the ability to manage sudden demand surges without adversely affecting system use.

C. The new KHIE solution shall provide performance metrics for measuring application availability, performance, and network connectivity.

D. The new KHIE solution shall be capable of providing notice, through a basic alerting functionality, when it is suspected that a data feed has stopped functioning correctly.

E. The new KHIE solution shall be capable of providing notice, through a variety of additional alerting tools, when it is suspected that a data feed has stopped functioning correctly.

50.7.2.10 IHE Framework A. The new KHIE solution shall allow providers to send documents to the HIE

where they can be registered, stored, and shared with other providers. The system must be able to accept, index, and repose these documents.

B. The new KHIE solution shall allow for the retrieval of registered documents and clinical data located in the system. Providers will access their EHR that is integrated with KHIE's XDS.b community and will select a document by way of the Registry Stored Query [ITI-18] transaction. The provider may select one or more documents from the returned list and the EHR returns them using the Retrieve Document Set [ITI-43] transaction.

86

C. The new KHIE solution shall create an on-demand document and register or include it in the XDS.b environment. The document will be composed of all data available to the on-demand function. The new transaction will enable the registration of on-demand Document Entries [ITI-61].

D. The new KHIE solution shall be able to handle XDS-i.b for radiology. E. The new KHIE solution shall be able to access data from a separate

community by way of IHE XCA/XCPD profile. The providers EHR system will query KHIE's document repository, prompting a query of other communities from the repository. Any documents found on the patient are listed in the return message to the EHR. If a particular document is requested, the KHIE system will retrieve and deliver the document.

F. The new KHIE solution shall be able to insert all pertinent Medicaid claims information collected in the CDR into the Generate On-Demand functionality.

G. The new KHIE solution shall support the Provide X-User Assertion [ITI-40] transaction. This transaction is utilized by the X-Service User to pass a claimed identity assertion to the X-Service Provider. The X-Service User and the X-Service Provider use the X-Assertion Provider as the third party issuer of the claimed identity assertion.

H. The new KHIE solution shall have the ability to provide extra protection based on a VIP indicator that is present in the eMPI.

I. The new KHIE solution shall be HealtheWay Certified for the EhealthExchange and be capable of cross community exchange with other HIEs and federal organizations including the Social Security Administration and the Veterans Administration.

50.7.2.11 Event Notification (Alert) System

A. The new KHIE solution shall have the capability to send an immediate or batch notification of event(s) (or Alert) using pre-determined rules. The solution shall allow a flexible content payload, using clinical information (including static and on demand documents) that is contained in or available to the system. For example, upon receipt of a discharge event from a hospital the primary care physician is sent an alert indicating this event including the available discharge summary from the hospital. The solution shall provide flexible delivery of those events, including but not limited to Direct message, file transfer to a clinical system or other system, text message, or web portal. Examples of the events of interest include ER admissions and discharges, inpatient stay admissions and discharges, and level of care changes. Each event shall be able to generate one or multiple notifications possibly delivered through multiple routes.

B. The Vendor shall configure the system to send ADT alerts to authorized recipients which have been defined in advance. The sending of ADT alerts by the system will be rule based and at a minimum provide: 1. The patient’s name 2. The patient’s location 3. The patient diagnosis 4. ADT specifications

87

C. The new KHIE solution shall be capable of receiving a regularly updated list of patients, for each notification established, from the entity responsible for its maintenance or provide a self-service function for that maintenance by the responsible entity.

D. The new KHIE solution shall allow the generation of alert messages that can be configured by the time of day and day of week, for each interface via user-defined peak, off-peak, and scheduled downtimes.

E. The new KHIE solution shall allow alert messages to be sent to any device including pagers and printers as well as to other interfaces. Alerts can also be configured based on change of interface status, idle time, and excessive transaction backlog.

50.7.2.12 Reporting and Analytics

Kentucky plans to implement a separate clinical reporting and analytics system called KY Health Trust, with which the new KHIE solution will be required to interface. For this reason the scope of reporting and analytics for this RFP will be limited to administrative reporting necessary to efficiently operate the KHIE. A. The new KHIE solution shall have a performance/service and metrics

dashboard to provide accessibility to overall system health as well as specific items of system health. The new KHIE solution shall provide both real-time and cumulative reporting of information and include a report for all agreed upon SLAs. The information provided shall include but not be limited to: 1. Active users (identifiable by user id and health system affiliation) 2. Daily activity reports including:

i. Number of messages passing through KHIE’s HISP ii. Active data feeds (with error reporting capability) iii. Daily query information (submitted documents, queries performed,

returned empty data sets) 3. Meaningful Use Reporting (monthly)

i. All Public Health data feed traffic ii. For each provider that has submitted a Summary of Care CCD, the

system shall log the queries for each registered Summary of Care CCD that were made by another provider. A report shall be available showing the number of CCDs submitted and of those the number queried. It shall use a list of desired providers to report on as input.

4. System performance metrics (query response time, data feed health monitoring) i. The Vendor shall be able to export data to the Kentucky Health Data

Trust by way of a real time data feed or batch file notification. ii. The new KHIE solution shall provide monitoring and guaranteed

delivery of interfaces and should provide a simplified dashboard for easy access and viewing of real-time health of all interfaces.

iii. The new KHIE solution shall be capable of providing notice, through a variety of alerting tools, when it is suspected that a data feed has stopped functioning correctly.

88

B. The new KHIE solution shall provide reports showing traffic/usage of Direct, to include but not limited to XDR traffic by participating Clinical Systems.

C. The new KHIE solution shall have the ability to capture all incoming raw data feed messages and capture all outgoing messages that are delivered to other systems (Immunization Registry, Biosense, NEDSS, Cancer Registry)

D. The new KHIE solution shall receive feeds of claims data from various MCO's, the KHDT or the Commonwealth's Medicaid Fiscal Agent.

E. The new KHIE solution shall report on all cross gateway queries supported by [ITI-38] transaction. The report should contain the”homeCommunity” id of the requesting gateway and the data that was sent supported by [ITI-39] transaction to the requesting gateway.

F. The new KHIE solution shall have error monitoring that provides an alert subsystem which generates alert messages that are stored and viewable online and can be routed via various mechanisms such as e-mail and texts.

G. The new KHIE solution shall include a variety of monitoring and troubleshooting tools that allow for the immediate identification and correction of any problem that is encountered. These intuitive tools are easy to access via "point and click" or "drag and drop" features.

H. Develop, maintain and provide access to records required by CHFS, Commonwealth and federal auditors.

I. The vendor shall provide a single repository for all Project Management artifacts and activities, including: tracking of all risks and issues, submission of deliverables, and status reports; posting of meeting schedules and meeting minutes etc.

J. Provide reports necessary to show compliance with all performance standards, including documentation requirements (artifacts) for CMS

K. Certification audits, System Development Lifecycle (SDLC) Reviews, and any other contract requirements. Assist with the provision of responses and required activities as a result of the above reviews.

L. Provide to CHFS status reports regarding the selected Vendor’s activities at agreed upon intervals. The selected Vendor shall provide reports with content and format agreed upon with CHFS. The intent of the reports is to provide CHFS and the selected Vendor with reliable up to date information to manage the progress of the project.

M. Prepare and submit to CHFS requests for system changes and notices of system problems related to the selected Vendor’s operational responsibilities.

N. Prepare and submit for CHFS approval suggestions for changes in operational procedures and implement the changes upon approval by CHFS.

O. Maintain electronic operational procedure manuals and update the manuals to be approved during the change management process.

P. Meet all federal and state privacy, confidentiality, and security requirements within the selected Vendor’s operation.

Q. Monitor the quality and accuracy of the selected Vendor's own work. R. Submit quarterly reports electronically or in hard copy of the overall project

quality assurance activities including quality assurance reviews, findings and corrective actions (if any) to CHFS.

89

S. Perform continuous analysis based on lessons learned to improve performance of Vendor functions and report the results of the analysis to CHFS.

T. Provide CHFS with a description of any changes to agreed processes for approval prior to implementation of the change.

U. For any performance falling below a Commonwealth-specified level, explain the problems and identify the corrective action to improve the rating.

V. Provide a written response to CHFS inquiries within two (2) business days, unless otherwise agreed to by both parties.

W. Maintain CHFS-approved documentation of the methodology used to measure and report completion of all requirements and attainment of all performance standards

50.7.2.13 Interfaces Interface Description Medicaid Eligibility Contains Medicaid Member eligibility information to be indexed into the

eMPI. Medicaid Medical and Dental Claims

Contains institutional, professional, and dental claims information.

Medicaid RX Claims Contains drug claims information. Receive Claims from APCD Receive claims information for other payers via the APCD. Provide Clinical information to KyHDT analysis

Provide copies of the CDR to system external to the KHIE for use by the KyHDT.

Immunization Registry Patient Demographics

IR contains demographics data and the KY IR ID number for patient matching during KHIE query.

State Lab Results Contains lab result information to be included in the HIE Community Health Record.

ELR-Lab KHIE receives lab result feeds from various labs and forwards what is reportable to NEDSS. This is the Lab system interface.

Provider/Hospital EHR’s Providers send HL7 messages to KHIE via three methods: MLLP over VPN, Web Services, Direct, and via a secure gateway that installs at the EHR location, receives MLLP and sends it to KHIE via a secure web service.

XDS.b The vendor shall implement and support XDS.b registry and repository functionality.

Immunization Registry Real-Time Query

The KHIE issues a QBP and receives back an RSP. This can be returned to the requester directly or parsed for inclusion in the on-demand C-CDA.

Immunization Update Providers submit VXU messages to KHIE who forwards them directly to the Immunization Registry.

ELR-NEDSS KHIE receives lab result feeds from various labs or providers and forwards what is reportable to NEDSS. This is the NEDSS interface.

SS-Biosense KHIE receives ADT messages from providers for patient registration and clinical information. From these messages, KHIE determines criteria for reporting to Biosense and creates the appropriate SS messages and forwards them. This is the Biosense SS interface.

Cancer Registry Oncology providers are to send cancer clinical information to the Cancer Registry (CR) using an existing connection to KHIE.

Medicaid Waiver PHR Using standard ITI query and response the HIE shall respond to a query request from the Medicaid Waiver PHR for the given patient activating the request. Patient identity/demographic information will be

90

provided from the Medicaid Waiver PHR. The Commonwealth enterprise data warehouse

KHIE should send copies of all data feeds to the Commonwealth enterprise data warehouse

PDMP (Prescription Drug Monitoring Program )

The Vendor shall implement and support PDMP query and response functionality

Table 5 – Interfaces required to be supported by KHIE include but are not limited to those listed in Table 5

91

50.7.2.14 ITI Transaction

Transaction Name

Description

ITI-01

Maintain Time This transaction is used to maintain time among multiple systems.

ITI-02 Get User Authentication

This transaction is used to authenticate an enterprise-wide user identity.

ITI-03 Get Service Ticket

This transaction is used by the Client Authentication Agent to obtain the service ticket that will be sent to a Kerberized Server to authenticate this user to a Kerberized Server.

ITI-04 Kerberized Communication

This transaction specifies the details of the association of a Kerberos user identity with a session for a session oriented protocol, or a transaction for a transaction oriented protocol.

ITI-08 Patient Identity Feed

This transaction communicates patient information, including corroborating demographic data, after a patient’s identity is established, modified or merged or after the key corroborating demographic data has been modified.

ITI-09 PIX Query This transaction involves a request by the Patient Identifier Cross-reference Consumer for a list of patient identifiers that correspond to a patient identifier known by the consumer. The request is received by the Patient Identifier Cross-reference Manager whom in turn processes the request and returns a list of corresponding patient identifiers.

ITI-10 PIX Update Notification

This transaction involves the Patient Identity Cross-reference Manager providing notification of updates to patient identifier cross-reference associations to Patient Identifier Cross-reference Consumers that have registered their interest in receiving such notifications.

ITI-11 Retrieve Specific Information for Display

This transaction involves the query of information for presentation purposes. This may occur when a user attempts to lookup information associated with a certain patient that is stored on a different system.

ITI-12 Retrieve Document for Display

This transaction involves the retrieval of a document (persistent object) for presentation purposes.

ITI-18 Registry Stored Query

This transaction supports a variety of types of queries to include: Query by patient (ID) for a time interval by document type(s), by practice setting(s) by author person Query by Document Source Query for XDS Folders updated during a time interval Query for all documents in a Folder or Submission Set Query by time of submission

ITI-19 Authenticate Node

This transaction supports a local Secure Node presenting its identity to a remote Secure Node, and authenticates the identity of the remote node. After the mutual authentication other secure transactions may take place through this secure pipe between the nodes. Additionally, the user requesting access to the node is

92

authenticated. ITI-20 Record Audit

Event In this transaction, there is an entry created by the application or user in the Audit Log that is located in the Audit Record Repository.

ITI-21 Patient Demographic Query

This transaction involves a request by the Patient Demographics Consumer for information about patients whose demographics data match data provided in the query message. The Patient Demographics Supplier receives and immediately processes the request and returns a response in the form of demographic information for matching patients.

ITI-30 Patient Identity Management

This transaction transmits patient demographics in a patient identification domain (i.e., patient identifiers assigned by the same assigning authority). The term “patient demographics” is meant to convey the patient identification and the full identity and information on persons that are related to this patient, such as the primary caregiver, family doctor, guarantor, and next of kin.

ITI-31 Patient Encounter Management

This transaction enables systems to share information with acute care settings for both inpatients and outpatients. This transaction carries events for creating, updating, and cancelling patient encounters. There are several optional message subsets to support a wide range of needs.

ITI-38 Cross Gateway Query

This transaction is based on the [ITI-18] Registry Stored Query transaction. The same set of stored queries is required to be supported and the options for the controlling what kind of data is returned are the same. This query is between an Initiating Gateway and a Responding Gateway.

ITI-39 Cross Gateway Retrieve

This transaction is semantically the same as the Retrieve Document Set transaction [ITI-43].

ITI-40 Provide X-User Assertion

This transaction is used by the X-Service User to pass a claimed identity assertion to the X-Service Provider. The X-Service User and X-Service Provider use the X-Assertion Provider as the third party issuer of the claimed identity assertion.

ITI-41 Provide and Register Document Set

This transaction passes a Repository Submission Request from a Document Source to a Document Repository; document Recipient, or a Metadata-Limited Document Source to a Document Recipient.

ITI-42 Register Document Set

This transaction passes a Submission Request from a Document Repository to a Document Registry.

ITI-43 Retrieve Document Set

This transaction is used by the Document Consumer to retrieve a set of documents from the Document Repository, On-Demand Document Source, or Initiating Gateway.

ITI-44 Patient Identity Feed HL7 V3

This transaction is identical to the [ITI-08] Patient Feed transaction.

ITI-45 PIXV3 Query This transaction is identical to the [ITI-09] PIX Query transaction. ITI-46 PIXV3 Update

Notification This transaction is identical to the [ITI-10] PIX Update Notification transaction.

ITI-47 Patient Demographics Query HL7 V3

This transaction is identical to the [ITI-21] Patient Demographic Query transaction.

ITI-61 Register On This transaction involves an ON-Demand Document Source

93

Table 6: IHE profiles required to be supported by KHIE include but are not limited to those listed in Table 6 50.7.3 Project Management Responsibilities

A. Prepare an outline and obtain approval from CHFS for the content, format, and acceptance criteria of each deliverable document before beginning work on the deliverable via a deliverable expectation document.

B. Responsible for taking minutes at meetings and providing written meeting minutes within two business days of the occurrence of that meeting. The selected Vendor shall provide sufficiently qualified business and technical staff to document decisions, actions and questions coming out of each meeting.

C. Provide all written documents and deliverables with a level of quality and completeness that indicates that they have been reviewed and proof read by the selected Vendor prior to being delivered to the Commonwealth. Indicators of quality and completeness include: 1. A standard of business and technical writing that limits ambiguity and

rework by CHFS; 2. A level of English proficiency that limits CHFS edits for grammar and

clarity; and 3. Content is in keeping with expectations set out in Deliverable Expectation

Documents and decisions captured in Joint Application Design (JAD) sessions and other meetings

D. Provide sufficient staff to conduct all project activities (including JAD sessions).

E. Obtain written approval from the Commonwealth on all final deliverables F. Revise deliverables, if required, using Commonwealth review findings to meet

content and format requirements. G. Develop, obtain approval for, and maintain project work plan. H. Identify issues related to the project using the Commonwealth-approved

process for documenting issues, processes for assigning issues to resources, and resolving issues.

I. Use Commonwealth-approved change control / management processes for implementing changes in scope.

J. Report progress against the work plan through weekly written status reports (or on a schedule agreed to by the Commonwealth), at weekly review meetings with the CHFS Project Manager, and through a weekly update of the work plan / task schedule.

K. Deliver written status reports and updated work plans / schedules one business day before the status meeting.

L. Identify scope of work issues. Specify the basis upon which an issue is out of scope, including appropriate RFP references.

M. Maintain all project documentation within the CHFS SharePoint domain, with access provided to Commonwealth staff. Vendor should ensure access

Demand Document Entry

passing a Submission Request to a Document Registry. The Document Source registers the patient specific on-demand document to the Document Registry.

94

restrictions are applied as appropriate to documentation such as financial or contract information. All documentation restrictions shall be approved by the CHFS Project Manager prior to loading of documents on the SharePoint.

N. Provide one (1) week in advance notice for all Commonwealth staff who are required to participate in project activities. Distribute agendas and other materials as appropriate forty-eight (48) hours prior to the event.

O. Document and track all action items through the CHFS SharePoint site.

50.7.4 Deliverables and Milestones The deliverable requirements shall be based on the following timeline. Therefore appropriate Cost Proposal items must also be based on the timeline.

Contract Execution Year 2

Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Implementation Contract Execution System Configuration Data Conversion Provider Connection Migration Potential Phase II

Ongoing Operations

Add new participants Ongoing Op's / Expansion

Figure 1: KHIE Timeline, Contract Execution Year 1, Quarter One begins at contract signing

A. Project Management Plan The Vendor shall submit a Project Management Plan based on Version 5 of the Project Management Body of Knowledge (PMBOK) sufficient to describe the overall project approach within ten (10) business days of contract signing.

B. Communication Plan The Vendor shall submit a Communication Plan to cover communication patterns and practices for the project. The document will be initially submitted within ten (10) business days of contract signing. This plan will be updated at various points in the project as the need arises.

C. General System Design Document The GSD will document the overall functionality of the system from a functional perspective.

D. Connectivity Guide The Vendor shall develop a connectivity guide sufficient to aid participant systems implementers in connecting to the KHIE and managing those connections.

E. Detailed System Design Document

95

The DSD will cover the entire system functionality in a detailed technical fashion. It will cover topics such as specific configurations, rule bases, security concepts, processes and procedures, and any other topic that makes connecting easy.

F. Data Conversion Plan The Vendor shall submit a conversion plan to detail the approach, schedule, resources, management, and execution of the conversion of all existing KHIE patient clinical and claims data collected for five (5) years since start into the new Vendor system. This plan shall be submitted within one (1) month of contract signing. The Commonwealth will ensure that the existing Vendor fully supports this effort.

G. System Test Plan Within one (1) month of contract signing, the Vendor shall submit a general test plan detailing the overall approach to system testing including user acceptance testing. This is not to be confused with testing provider feeds into an already established system. This test plan is for the implementation of the HIE system itself.

H. Implementation Plan Within two (2) months of contract signing, the Vendor shall submit an implementation plan detailing the general schedule and approach for system implementation. This plan shall be updated during User Acceptance Testing to include finer detail.

I. Provider Migration Plan Within two (2) months of contracting signing the Vendor shall submit a plan detailing the strategy for migrating providers from the old system to the new system.

J. Operational Support Plan Within two (2) months of contract signing, the Vendor shall submit an Operational Support Plan detailing all of the processes and procedures to be followed post go-live to keep the system running smoothly.

K. Training Plan The vendor shall provide a training plan for the Commonwealth staff and a separate training plan for the providers.

L. Provider Test Plan The vendor shall provide a test plan for the Commonwealth staff and a separate test plan for the providers.

M. Turnover Plan Within two (2) months of the go-live date, the Vendor shall submit a turnover plan detailing how they will make all data, configuration and other salient information available to a succeeding vendor. The Vendor shall maintain the plan throughout the contract period. The final updated version will be submitted to the Commonwealth no later than nine months before the end of the contract.

96

SECTION 60 – PROPOSAL SUBMISSION

60.1 Disposition of Proposals All proposals become the property of the Commonwealth of Kentucky. The successful proposal shall be incorporated into the resulting contract by reference. Disposal of unsuccessful proposals shall be at the discretion of the Commonwealth Buyer.

60.2 Rules for Withdrawal of Proposals Prior to the date specified for receipt of offers, a submitted proposal may be withdrawn by submitting a signed written request for its withdrawal to the Commonwealth Buyer.

60.3 Commonwealth’s Right to Use Proposal Ideas

The Commonwealth of Kentucky shall have the right to use all system ideas, or adaptations of those ideas, contained in any proposals received in response to the RFP. Selection or rejection of the proposal will not affect this right.

60.4 Submission of RFP Response

Each qualified offeror shall submit only one (1) proposal. Alternate proposals shall not be allowed. Failure to submit as specified shall result in a non-responsive proposal.

The vendor should complete the "Vendor" box on the face of the solicitation. An authorized representative of the vendor shall sign where indicated on the face of the solicitation. If the solicitation is not signed the proposal shall be deemed non-responsive. Acknowledgment of Addenda It is the vendor's responsibility to check the web site for any modifications to this solicitation. If modifications have been made, the vendor's signature is required on the latest addendum. Failure to acknowledge the latest addendum of this solicitation shall cause the bid to be deemed non-responsive if the latest addendum is material to the procurement. Acknowledgment shall be received prior to the hour and date specified for receipt of offers. Verbal acknowledgment shall not be accepted.

60.5 Format of Response

A. Proposals shall be submitted in two (2) parts: the Technical Proposal and the Cost Proposal.

1. The Technical Proposal should include one (1) marked original,

ten (10) copies, and five (5) CDs (in Microsoft Word, Microsoft Excel or PDF). (Do not submit thumb drives, flash drives, etc).

97

2. The Cost Proposal should include (1) marked original, five (5) copies, and five (5) CDs (in Microsoft Word, Microsoft Excel or PDF). (Do not submit thumb drives, flash drives, etc).

B. *Proposals shall be sealed and submitted to the Commonwealth Buyer by

the RFP Closing Date and Time (both are identified on the Cover Page of this RFP). ANY PROPOSAL RECEIVED AFTER THE CLOSING DATE AND TIME SHALL BE REJECTED AND RETURNED UNOPENED TO THE VENDOR AT THE VENDOR’S EXPENSE. *The Commonwealth defines SEALED as “a closure that must be broken to be opened and that thus reveals tampering”. (Merriam-Webster Dictionary, http://www.merriam-webster.com/dictionary/seal)

Should differences be determined to exist between the hardcopy proposal and the electronic version, the hardcopy shall prevail. Pricing shall only be provided in the Cost Proposal. DO NOT SUBMIT ANY PRICING INFORMATION IN THE TECHNICAL PROPOSAL. The outside cover of the package containing the Technical Proposal should be marked:

Kentucky Health Information Exchange System (KHIE) RFP 758 1700000069

TECHNICAL PROPOSAL Name of Offeror

Closing Date and Time

The outside cover of the package containing the Cost Proposal should be marked:

Kentucky Health Information Exchange System (KHIE) RFP 758 1700000069

COST PROPOSAL Name of Offeror

Closing Date and Time

All submitted Technical and Cost Proposals shall remain valid for a minimum of six (6) months after the proposal due date.

60.6 Technical Proposal Content

A. Transmittal Letter The transmittal letter should be on the vendor’s letterhead, notarized and signed by an agent authorized to bind the vendor. The transmittal letter should include the following:

98

i. A statement that deviations are included, if applicable. Proposed deviations must be outlined in the transmittal letter.

Any deviation from the provisions of the solicitation must be specifically identified by the vendor in its proposal, which if successful, shall become part of the contract. Such deviations shall not be in conflict with the basic nature of this solicitation. The Commonwealth reserves the right to reject any and/or all deviations in whole or in part.

ii. A sworn statement that, if awarded a contract as a result of this solicitation, the vendor shall comply in full with all requirements of the Kentucky Civil Rights Act, and shall submit all data required by KRS 45.560 to 45.640;

iii. A sworn statement pursuant to KRS 11A.040 that the vendor has not knowingly violated any provisions of the Executive Branch Code of Ethics;

iv. A sworn statement of that the vendor is in compliance with Prohibitions of Certain Conflicts of Interest;

v. A statement of certification in accordance with In accordance with Federal Acquisition Regulation 52.209-5, Certification Regarding Debarment, Suspension, and Proposed Debarment that to the best of its knowledge and belief, the vendor and/or its principals is (are) not presently debarred, suspended, proposed for debarment, or declared ineligible for the award of contracts by any State or Federal agency.

vi. The name, address, telephone number, fax number, and email address of the contact person for this RFP. The address shall be one in which the major overnight delivery services will deliver; and

vii. The name, address, telephone number, fax number and email address of the contact person to serve as a point of contact for day-to-day operations.

viii. Subcontractor information to include name of company, address, telephone number and contact name, if applicable.

ix. Acknowledgment that your company will protect personal information in accordance with Kentucky’s Personal Information Security and Breach Investigation Procedures and Practices Act, KRS 61.931. (see Attachment E)

B. Disclosure of Violation of Statutes Pursuant to KRS 45A.485, contractors are required to reveal final determinations of violation of certain statutes incurred within the last five (5) years and be in continuous compliance with those statutes during the contract. Where applicable, the vendor is required to complete and submit Report of Prior Violations of Tax and Employment Laws.

C. Kentucky Tax Registration Application

Revenue Form 10A100, Kentucky Tax Registration Application effective July 2008, is a form to be completed by any person or entity wishing to

99

contract with the Commonwealth to provide goods or services subject to sales and use tax pursuant to KRS 139.200. The form is located at this web-link as Attachment 5:

http://finance.ky.gov/services/eprocurement/Pages/VendorServices.aspx

In accordance with administrative regulation 200 KAR 5:390, this form has to be completed and submitted, before a contract can be awarded. Section 2 of the regulation also notes: “Failure to submit the required documentation or to remain registered and in compliance with the sales and use tax filing and remittance requirements of KRS 139.540 and KRS 139.550 throughout the duration of the contract shall constitute a material breach of the contract and the contract may be terminated.”

D. Registration with the Secretary of State by a Foreign Entity

Pursuant to KRS 45A.480(1)(b), an agency, department, office, or political subdivision of the Commonwealth of Kentucky shall not award a state contract to a person that is a foreign entity required by KRS 14A.9-010 to obtain a certificate of authority to transact business in the Commonwealth (“certificate”) from the Secretary of State under KRS 14A.9-030, therefore, foreign entities should submit a copy of their certificate with their solicitation response. If the foreign entity is not required to obtain a certificate as provided in KRS 14A.9-010, the foreign entity should identify the applicable exception in its solicitation response. Foreign entity is defined within KRS 14A.1-070. Businesses can register with the Secretary of State at: https://secure.kentucky.gov/sos/ftbr/welcome.aspx .

E. Required Affidavits (see Attachment C)

F. Completed and signed face of solicitation (see Section 60.4) G. Signed face of latest addendum of the solicitation (see Section 60.4)

H. EEO Forms if applicable (see Section 40.21)

I. Proposed Solution (see Section 60.7)

60.7 Proposed Solution Content

Response should be based on the RFP requirements. Responses should include the following:

Executive Summary: (Four (4) page limit). Briefly describe the Offeror’s proposal. Summary should highlight the major features of the

100

proposal. An evaluator should be able to determine the essence of the proposal by reading the executive summary.

a. Corporate Background and Experience: The purpose of this

section is to assure that the Offeror has the corporate capacity necessary to provide the services required by the Department and will remain viable and strong through the term of the contract. In this section, please provide: Background:

1) Complete company name; 2) Date established; 3) State in which incorporated; 4) If company has a parent company, what is it and how long

has this relationship existed; 5) Ownership (such as public company, partnership,

subsidiary); 6) Narrative description of company‘s organization (include

organization charts and indicate company officers where applicable);

7) Primary contact name, title, phone and e-mail. 8) Total number of full-time employees; 9) State and location of the office that will address all support

questions/issues; 10) Number of personnel engaged in implementation activities; 11) Primary services or products offered by the company; 12) Offeror‘s support organization including: number of field

resource organizations; hours of support site/phone lines 13) Product Name(s) and version number(s) 14) Date next version is expected general availability

Experience:

1) Length of time in the HIE systems business; 2) Length of time similar to proposed systems have been up

and running; 3) Number of customers with full implementations of the HIE

modules or systems; 4) Organized national and/or regional user groups; 5) List all HIPAA violations and corrective actions taken; 6) Experience with governmental informational projects of

similar size and complexity. 7) Experience, processes and commitment for addressing

customers’ issues and requests. Provide examples within past projects that highlight where the Offeror demonstrated commitment and follow-through as a business partner, beyond or other than simply meeting contract requirements.

101

In addition, please provide a listing of all projects currently in production using the proposed system completed in the past three (3) years. Include the following information for each project:

1) Customer/Organization Name and 2) Customer/Organization Address Time Period of Contract 3) Brief Statement of Scope of Project (include personnel

requirements); 4) Contract cost; 5) Staff-months expended; and 6) Lists of Major Contract Disputes.

Financial:

1) Gross and net revenues during the last three (3) years related to HIE system business; and

2) Research and development investment in the past three (3) years.

b. Proposed Project Team Experience: Please submit the names

and organizational relationships of project team personnel who will provide services according to this RFP. These should include the Project Director, Back-Up Project Director, and primary staff assigned to this project. In addition, please include the maximum Vendor person-hours dedicated to the implementation Please submit a staffing plan including resumes (do not include personal information such as social security number, address, etc) for all project personnel and provide the following:

1) Experience with Offeror; 2) Certification certificates indicating that listed personnel are

certified/qualified to service the Offeror‘s software; 3) Experience relating to implementation, training and service

support of HIE systems; 4) Name, position, of the vendor’s key project management

person who is expected to be with the project through all phases including demonstrations, implementation and ongoing support. Listing of relevant projects with customer names, time periods and brief description of project scope;

5) Experience in implementing turnkey HIE systems;

c. Security Plan: Please describe how this plan will be regularly updated and provided to the Commonwealth for review. Please provide evidence that the proposed cloud solution meets those

102

standards and explain the security controls in place to maintain meeting those standards.

Please provide a response to the system’s ability to define and control user and role profiles within and across different facilities. Please include an explanation of the ability to handle marking information as sensitive as well as having a VIP status.

Describe the process in which roles are created and how access to PHI is granted and revoked. Describe how accounts are maintained and expired. Describe how your organization would respond to a data security breach. Provide proof of an annual SSAE-16 audit of the data center which will be used to host the KHIE solution and will commit that the audit will be conducted annually during the duration of any contract with the Commonwealth.

d. Risk Management Plan: Please provide a list of project-related risks that will be tracked and avoided or mitigated based on previous installations similar in size, scope and functionality as KHIE. List any “priority one” or “high” risks identified during similar systems implementation and how KHIE should, and the Offer or will, attempt to avoid any high risks. State how Offer or intends to track and control any “priority one” or “high” risks identified during systems implementation, particularly those risks associated with project schedule and/or project cost.

e. Infrastructure, Disaster Recovery and Redundancy Plan: Please provide the Plan for the solution‘s hosted infrastructure environment clearly describing the operational and technical model to include: Items required to operate an alternate disaster recovery site for continued operation in the event of a disaster. A description of all services, hardware, software, and software licenses. Explanation of the built-in redundancy including the network redundancy to prevent any disruption due to the loss of internet connection, etc. in the event of a prolonged outage.

103

Explanation of how Offeror will ensure zero (0) data loss in the event of a disaster. Describe how often backups are performed on the system, whether they are encrypted and how long they are retained. Describe the expected Recovery Time Objectives (RTO) in case of primary data center failure.

f. Software Requirements: Describe Offeror’s release management strategy, define the major, minor or other release types and describe the impact of those releases to production (typical down times). Which release types are included in ongoing maintenance fees and which will cost additional to obtain. Describe how often routine maintenance is performed on system and what additional functionality should the Commonwealth expect to be included in each type of maintenance. Please provide the following information regarding product enhancement requests and reporting software issues or bugs:

1) What is the process when the Commonwealth wants to report a bug or add an enhancement?

2) What is your change management process and are release notes included for enhancements and new releases?

3) How bug fixes and enhancements are tracked. 4) Please provide statistics about your bug fix and

enhancement track record. Provide and explain the product roadmap. For example explain whether the system supports XDS-i.b and if not then provide a status including what work has been done to date to support this and when it is expected. Describe:

1) The minimum bandwidth requirements for systems connected to the HIE

2) The minimum storage requirements for systems connected to the HIE

3) The minimum memory requirements for systems connected to the HIE

4) If the product requires any type of application or agent to be installed on the client and if so, what needs to be installed and how is it maintained

5) The security requirements for client

104

6) The minimum network bandwidth requirements at each facility

Explain and demonstrate all reporting capabilities and provide examples of required reporting. The solution should be a browser agnostic application. The solution should be automatically adaptable to all screen sizes.

g. KHIE Functional Requirements: Table 7 contains the solution requirements that the new KHIE solution shall have. Please describe how you will meet the KHIE Functional Requirements as defined by this table and Section 40.

No. Solution Requirement 1. Registration

1.1 The new KHIE solution shall be configured so that the HIE has the ability to receive new patient demographics along with the Clinical System's MRN. The HIE loads this data to the MPI, which matches it to other records, and adds the Clinical System as a record location for the patient.

1.2 The new KHIE solution shall have the ability to perform patient registration based on any "feed". A "feed" is an ongoing submission of messages of a particular HL7 type and event form a particular source. For example, ADT^A03 messages form Hospital A is a separate feed from ADT^A08 messages from the same source.

2. Testing

2.1 The new KHIE solution shall test incoming data feeds from clinical systems to ensure that the proper specifications are being followed.

2.2 The system needs to test the HL7 clinical feeds from any potential CS prior to the CS being promoted to the production environment.

2.3 The vendor shall provide access to messages for onboarding verification. 3. Security

3.1 The new KHIE solution shall comply with all Commonwealth Security Standards detailed in section 30.040 of this RFP.

3.2 The new KHIE solution shall provide privacy and security components that follow national standards and meets all HIPAA security and privacy requirements.

3.3 The system hardware recommendations shall meet national security guidelines.

3.4 The data center where the solution is hosted shall be either NIST 800-53 rev. 3, NIST 800-53 rev. 4 or FedRAMP certified.

3.5 The new KHIE solution shall secure the patient's data at all times and in all modules of the product (e.g. encrypted at rest, data encrypted in motion, data on handheld devices).

3.6 The new KHIE solution shall allow KHIE to configure or set the number of unsuccessful user logon attempts before locked out.

3.7 The new KHIE solution shall provide a "time out" feature that automatically signs off a user if a workstation has been left unattended for a user-configured time period.

3.8 The new KHIE solution shall support role based access.

105

3.9 The new KHIE solution shall provide different levels of security based on user role, site, and/or enterprise settings.

3.10 The new KHIE solution shall permit the security administrator to set events that are considered security violations as well as provide real-time notification of any violations.

3.11 The new KHIE solution shall provide termination of user sessions/connections by an administrator if a breach is suspected.

3.12 The new KHIE solution shall have the ability to configure individual user interface components to exhibit the appropriate behavior based on the user's roles.

3.13

The system shall support protection of confidentiality of all Protected Health Information (PHI) delivered over the Internet or other known open and internal networks via encryption using type-DES(3DES) or the Advanced Encryption Standard (AES) and an open protocol such as TLS, SSL, IPSec, XML encryptions, or S/MINE or their successors.

3.14 In regards to 42 CFR, the system shall be able to protect the health information of the behavioral health record.

3.15

The Kentucky Online Gateway (KOG) (maintained by the Commonwealth) provides user provisioning and authorization services. The new KHIE solution shall utilize the KOG solution for user provisioning and authorization services. KHIE shall interface with KOG through Active Directory Federation Services (ADFS) for SSO (Single Sign-On). The solution shall be ADFS/WS Federation/Security Assertion Mark-Up Language (SAML) 2.0 compliant and use Claims for Authentication and Authorization. KOG supports both active (WS-Trust) and Passive (WS-Federation and SAML 2.0) scenarios. The new KHIE solution shall invoke KOG services prior to executing a user request from within the KHIE solution. The Vendor is responsible for the interface between the KHIE solution and the KOG.

3.16 The new KHIE solution shall support access based on SAML tokens and the claims encased therein. In addition, The new KHIE solution shall support global sign off in accordance to KOG specifications.

3.17 The new KHIE solution shall allow Kentucky to own the individual account certificates or they shall be transferable at a future date.

4. Security Logging and Audit 4.1 The new KHIE solution shall support the ATNA profile and TLS.

4.2 The new KHIE solution shall have the ability to provide audit logs/error logs to detect unauthorized access, activity, lockouts and automatically and proactively report to Commonwealth Security Staff.

4.3 The new KHIE solution shall have the ability to provide an audit trail that can be used to identify transactions or data accesses that have been performed. Examples are by date range, function, terminal, patient, and user.

4.4 The new KHIE solution shall have the ability to provide audit log reporting features. 5. Documentation

5.1 The vendor shall provide a documented process for their approach to custom software development regarding the user experience (workflow and branding) and the architecture, specifically, general and detailed systems design.

106

5.2

The vendor shall provide the following document deliverables: -Project Management Plan -Communications plan -General system design document -Connectivity guide -Detailed system design document -Data conversion plan -System test plan -Implementation plan -Provider migration plan -Operational support plan -Training plan -Provider test plan -Turnover plan

6. Infrastructure 6.1 The new KHIE solution shall support Web services access utilizing SOAP and TLS.

6.2 The new KHIE solution shall conduct routine backup procedures (or an equivalent) without the users having to be off the system.

6.3 The new KHIE solution shall have the ability to provide common reporting tools and analytics that are compatible with recognized, industry standard reporting tools such as Business Objects, Cognos, Microsoft SSRS, etc.

6.4 The vendor shall provide load testing tools and load testing as part of their implementation.

6.5 The new KHIE solution shall be scalable to accommodate additional utilization, users, transactions and/or additional local/remote sites.

6.6 The new KHIE solution shall support multiple environments including development, test, QA, training and production.

6.7 The new KHIE solution shall provide monitoring of the HIE infrastructure and provide notification to KHIE administrators when errors or failures occur.

6.8 The new KHIE solution shall support the ability to receive data via secure Web Services, VPN, and Minimal Low Level Protocol (MLLP) over Virtual Private Network.

6.9 The new KHIE solution shall maintain Infrastructure standards certification of ISO/IEC 27002.

6.10 The new KHIE solution shall have the capability to be securely accessed from any location with an internet/broadband connection and is compatible with current leading web browsers such as IE, Chrome, Firefox.

6.11 Upon system turnover all information shall be made available to the successful bidder in XML, X-12, HL7, CSV, or comma delimited text or other means as mutually agreed upon by the vendors and the Commonwealth.

6.12 The new KHIE solution shall be covered under Vendor's Business Continuity and Disaster Recovery plan.

6.13 The new KHIE solution shall support and implement redundancy/fault tolerance for system availability.

6.14 The new KHIE solution shall conduct routine backup procedures (or an equivalent) without the users having to be off the system.

107

6.15

The new KHIE solution shall receive feeds of claims data from various MCO's and the Commonwealth's Medicaid Fiscal Agent. The new KHIE solution shall change the format of the data from administrative to clinical, summarize, and then filter. The new KHIE solution shall parse the claims data into the CDR in order to share it through the Provider Portal and IHE documents. Data will be provided daily through file exchange or, in some cases, in real-time by way of web services. Claims can be reversed or adjusted requiring HIE to process updates. The new KHIE solution shall process these updates as they are received and in the order in which they occurred on the source system. The Commonwealth will provide a means by which this order can be determined.

6.16 The new KHIE solution shall be able to export data to the Kentucky Health Data Trust by way of a real time data feed or batch file notification.

6.17 The new KHIE solution shall support the following document types: - CCD -CCDA -Any future IHE standards

6.18

The new KHIE solution shall support a variety of data input methods including but not limited to: -HL7 messages -Healthcare Medical and Pharmacy claims -Dental claims -HL7 Clinical Documents such as C-CDA -IHE profiles

6.19 The vendor shall provide future software releases and updates to all applications as part of regular maintenance fees.

6.20 The new KHIE solution shall provide a method for archiving patient health information, and all supporting electronic files (including application software files)

6.21 The vendor shall provide a schedule for routine maintenance as well as providing a notification method for scheduled system maintenance.

6.22 The vendor shall provide a documented process for notifying KHIE and all participating providers of any planned feed outages.

6.23 The vendor shall provide a documented process for performing all emergency maintenance to the system.

6.24 The new KHIE solution shall support industry standard including HL7, CCR, CCD, and CDA at a minimum.

6.25 The new KHIE solution shall support standard HL7 interfaces.

6.26 The new KHIE solution shall have the ability to interface via HL7 compatible interface for receiving ADT information.

6.27 The new KHIE solution shall allow users to view a display of archived transactions and audit file as well as the transactions as they are being processed.

6.28 The new KHIE solution shall provide its own eMPI, which can be any technology of the implementer’s choice so long as it is capable of registering entities with the Commonwealth's Master Data Management (MDM) solution, which is IBM's MDM product.

6.29 The new KHIE solution shall have the ability to account for and log any records that were merged and unmerged based on algorithms. This information shall be made available to the KHIE staff on demand.

7. Performance Reliability

108

7.1 The new KHIE solution shall provide performance metrics for measuring application availability, performance, and network connectivity.

7.2 The new KHIE solution shall have the ability to manage sudden demand surges without adversely affecting system use.

7.3

The new KHIE solution shall receive feeds of claims data from various MCO's and the Commonwealth's Medicaid Fiscal Agent. The new KHIE solution shall change the format of the data from administrative to clinical, summarize, and then filter. The new KHIE solution shall parse the claims data into the CDR in order to share it through the Provider Portal and IHE documents. Data will be provided daily through file exchange or, in some cases, in real-time by way of web services. Claims can be reversed or adjusted requiring HIE to process updates. The new KHIE solution shall process these updates as they are received and in the order in which they occurred on the source system. The Commonwealth will provide a means by which this order can be determined.

7.4 The new KHIE solution shall have a provider portal which allows providers access to both the query functionality and to the Direct.

7.5 The online transactions shall average below three (3) seconds or less response time for all non-reporting functions. The response time for all non-reporting functions shall not exceed thirty (30) seconds at any time.

7.6 The systems patient matching logic shall allow for customizations which would be unique to KHIE if desired. This must be explained and demonstrated.

8. Public Health Reporting

8.1 The new KHIE solution shall support direct pass-through of immunization updates, history queries and query responses as defined in the Center for Disease Control HL7 2.3.1 and above Implementation Guide for Immunization Messaging.

8.2 The new KHIE solution shall be configured to forward all Syndromic Surveillance messages from HIE to subscribing systems such as Biosense.

8.3 The new KHIE solution shall be configured to utilize the ADT information contained in SS messages for patient identification and forward the SS messages to subscribing systems such as Biosense in accordance with CDC Syndromic Surveillance specifications.

8.4

The new KHIE solution shall receive lab result HL7 messages from connected lab and provider systems, include that information in the CDR determine what is reportable to NEDSS according to DPH specifications, and output an appropriate message to be consumed by NEDSS via PHIN-MS following industry standards for Electronic Laboratory Reporting.

8.5 The new KHIE solution shall receive and forward cancer case data to the Kentucky Cancer Registry (CR).

9. IHE 9.1 The new KHIE solution shall support standard web service connectivity for IHE

profiles.

9.2 The new KHIE solution shall allow providers to send documents to the HIE where they can be registered, stored, and shared with other providers. The system must be able to accept, index, and repose these documents.

9.3 The new KHIE solution shall be able to create an on-demand CDA/C-CDA document that is registered in the XDS.b environment. The document will be composed of data from the CDR on a specified patient.

109

9.4

The new KHIE solution shall be able to access data from a separate community by way of IHE XCA profile. The providers EHR system will query KHIE's document repository, prompting a query of other communities from the repository. Any documents found on the patient are listed in the return message to the EHR. If a particular document is requested, the KHIE system will retrieve and deliver the document.

9.5 KHIE needs to connect to e-Health Exchange; therefore needs to be HealtheWay certified.

9.6 The new KHIE solution shall be able to insert all Medicaid claims information collected in the CDR into the Generate On-Demand functionality.

9.7

The new KHIE solution shall be configured to support the Provide X-User Assertion [ITI-40] transaction. This transaction is utilized by the X-Service User to pass a claimed identity assertion to the X-Service Provider. The X-Service User and the X-Service Provider use the X-Assertion Provider as the third party issuer of the claimed identity assertion.

10. Query Based Exchange

10.1

When queried, the system shall return all matching patients with sufficient demographics to extinguish any ambiguities. Once the patient is selected, the system shall display the available documents being either static or dynamic. If the provider selects a static document, the system shall retrieve the document form the document repository. If the provider chooses a dynamic document, the system shall gather the clinical information from the CDR and create the requested clinical document.

10.2

The new KHIE solution shall support returning documents to an external personal health record (PHR) system implemented by the state which provides a standard IHE based Query. It shall send the available static and dynamic documents to the PHR for the PHR to display in its own environment. The PHR will be able to provide the proposed system with a unique identifier for each patient queried.

10.3 The new KHIE solution shall support that all queries also query the immunization registry using Query By Parameter (QBP) as specified by the Commonwealth during JAD sessions in order that the immunization history result is included in KHIE query results.

10.4

The new KHIE solution shall have the ability to receive clinical messages in HL7 format from various providers in order to support the community health record. The data being sent is matched to the existing patient; additionally, the clinical data is then parsed and stored in the CDR. In the event that a clinical message is sent pertaining to a patient that has not been registered the solution shall at least store the message in an error queue and bring it to the attention of the KHIE technical staff. However if matching information is available it should be used to match the record if possible.

10.5 The new KHIE solution shall programmatically monitor and perform a nightly cleanup of the error queue using any newly available information in the MPI.

11. Directed Exchange

11.1

The new KHIE solution shall include but not limited to the following Direct features and functions: -Direct Addresses -Security and Trust Authority Services -DIRECT Messages (RFC 5322) - Message Transport & Delivery - Simple Mail Transport Protocol (SMTP) -Provider Directory

11.2 The new KHIE solution shall be Direct Trusted Agent Accreditation Program (DTAAP) accredited.

110

11.3 The Vendor shall ensure the minimum DTAAP identification and provisioning process steps are in place prior to issue of an X.509 certificate. (note that these are minimum requirements)

11.4 In the new KHIE solution certificate discovery shall occur prior to a DIRECT message being sent in order to fulfill the encryption functions of the S/MIME format. Discovery must be based on existing Internet protocols (existing specifications for discovery via DNS (If DNS is not supported, an alternate method must be offered)).

11.5 The new KHIE solution shall support automated certificate publication and resolution that operates intra and inter HISP.

11.6 The new KHIE solution shall afford KHIE the ability to provide HISP services to Clinical Systems who are XDR enabled and HISP agnostic. Additionally, the system shall be able to report separately the messages that have XDR to SMTP translation.

11.7 The new KHIE solution shall associate Direct accounts created within the new KHIE solution and their associated certificates generated with a DIRECT domain to be determined by KHIE (e.g. [email protected]).

11.8 The new KHIE solution shall define the options available for single year and multi-year cycles for Direct accounts created within the new KHIE solution and associated certificates generated for them.

11.9 The new KHIE solution shall be able to add external non-DTAAP accredited HISPs as trusted entities at the direction of KHIE.

11.10 The new KHIE solution shall support routing and delivery of valid Secure/Multipurpose Internet Mail Extensions (S/MIME) payload types (e.g. HL7 messages, CCD/CCR, PDF, Word Document, etc.).

11.11 The new KHIE solution shall be able to format the “payload” as an Internet Message Format (IMF) RFC5322-compliant email message with a valid MIME body (RFC 2045, RFC 2046).

11.12 The new KHIE solution shall demonstrate routing (inter and intra HISP) transactions originated from any DIRECT account within and outside of the domain.

11.13

The new KHIE solution shall support DIRECT-compliant gateways that implement the Applicability Statement for Secure Health Transport specification while harmonizing local standards/mechanisms to DIRECT-equivalents. (e.g., XDR and XDM for Direct Messaging specify such a solution when using IHE XDR for local transport, ITI and S&I). http://wiki.directproject.org/Applicability+Statement+for+Secure+Hea%20lth+Transport

11.14 The Vendor shall provide a list of all EHR systems to which they have developed DIRECT messaging interfaces and describe those that are currently live and any that are planned, including the technical details of how this is accomplished.

11.15 The new KHIE solution shall provide automatic notification of the receipt of a new DIRECT message to a user's regular email account.

11.16 The new KHIE solution shall operationalize the ONC July 2012 Implementation Guidelines for State HIE Grantees on Direct Infrastructure & Security/Trust Measure for Interoperability.

11.17 The new KHIE solution shall provide a Provider Directory for DIRECT users that are established accounts within the Direct environment.

11.18

The new KHIE solution shall provide a template for the KHIE staff to use to import file extracts from external "regional" provider directories. The import function and template shall allow for Add, Replace or Empty and be separate from the internal established accounts. It should allow for additional user defined fields which are not required and beyond the required set.

111

11.19 The new KHIE solution shall provide the ability for a user to export the entire provider directory or user-selected portion of the directory for import into an EHR system.

11.20 The new KHIE solution shall comply with ONC supported standards direction related to Provider Directory services. These may include ASC X12 Transaction 274 and 275, and /or IHE XD*. The Vendor shall present material in regard to their involvement in and tracking on these evolving standards initiatives.

11.21

The new KHIE solution shall be able to establish and maintain relationships between individuals and entities (individuals associated with 1 or many entities) as appropriate (e.g., Dr. X at Clinic A), following the recommendations and standards established through the ONC. The directory should support multiple DIRECT addresses for an individual or entity.

11.22 The new KHIE solution shall provide a folder level export of all active mailboxes upon contract termination.

11.23 The new KHIE solution shall support resolution of DIRECT Addresses issued by KHIE and other certificate granting authorities issuing DIRECT addresses (e.g. [email protected], [email protected], [email protected]).

11.24 The new KHIE solution shall support distributed granting (certificate assigned to an entity who assigns to employees) of X509 V3 certificates to trusted nodes/entities and align trust structure for these certificates as part of the Provider Directory.

11.25 The new KHIE solution shall support the ability to serve as proxy for a certified individual or entity, at the request of that individual or entity based on local storage of a private key for that individual or entity.

11.26 The new KHIE solution shall automatically assess and evaluate trustworthiness of certificates issued by Certificate Authorities that are routed by other HISPs presented in the course of sending and receiving messages DIRECT Messages.

12. Event Notification

12.1

The new KHIE solution shall have the capability to send an immediate or batch notification of event(s) (Alert) using pre-determined and configurable rules. The recipients will vary based on their role in treatment and/or their relationship to the patient and a flexible delivery of those events is required including but not limited to Direct message, file transfer to a clinical system or other system, text message, or web portal. Examples of these events of interest include ER admissions and discharges, inpatient stay admissions and discharges, and level of care changes. Each event must be able to generate one or multiple notifications possibly delivered through multiple routes.

12.2 The new KHIE solution shall have the capability to send an immediate or batch notification of event(s) using pre-determined rules based on the entire HIE data set, including Medicaid Claims data. Prefer a flexible delivery of those events including but not limited to Direct message, or file transfer.

12.3

The vendor shall configure the system to send notifications base on specific Admit, Transfer and Discharge codes for those systems which are providing ADT data feeds. The sending of these ADT notifications will be rule based and at a minimum provide: -Patient's name -Patient's location -Diagnosis -ADT specifications

12.4 The new KHIE solution shall allow the generation of alert messages that can be configured by the time of day and day of week, for each interface via user-defined peak, off-peak and scheduled downtimes.

112

12.5

The new KHIE solution shall support detecting when a patient is re-admitted to any connected hospital within 30 days of discharge from that or another connected hospital and report that event to the original discharging hospital. The new KHIE solution shall be configurable to be selective on the diagnosis at discharge. For example, a patient is discharged after being hospitalized for pneumonia. A week has passed and they are still feeling ill, prompting them to return to the original or any other connected hospital for further care.

12.6

The new KHIE solution shall support detecting when a patient is re-admitted to any connected mental health facility within 30 days of discharge from that or another connected mental health facility and report that event to the original discharging facility. The new KHIE solution shall be configurable to be selective on the diagnosis at discharge and readmission.

13. HIE Monitoring and Reporting

13.1 The new KHIE solution shall have error monitoring with notification message options including stored and viewable online and can be routed via various mechanisms such as e-mail and texts.

13.2 The new KHIE solution shall include a variety of monitoring and troubleshooting tools that allow the responsible KHIE staff to immediately identify and correct any problem that are encountered. These intuitive tools are easy to access and use via "point and click" or "drag and drop" features.

13.3

The new KHIE solution shall provide reports showing traffic/usage of Direct, to include but not limited to XDR traffic by participating Clinical Systems. The new KHIE solution shall have the ability to capture all incoming raw data feed messages and capture all outgoing messages that are delivered to other systems (Immunization Registry, Biosense, NEDSS, Cancer Registry)

13.4 The new KHIE solution shall report on all cross gateway queries supported by [ITI-38] transaction. The report should contain the home Community id of the requesting gateway and the data that was sent supported by [ITI-39] transaction to the requesting gateway.

13.5 The new KHIE solution shall all authorized KHIE staff to be able to export data to the Kentucky Health Data Trust by way of a batch file or be able to have a real time data feed.

13.6

The new KHIE solution shall have a performance/service and metrics dashboard to provide accessibility to overall as well as specific items of system health. The information provided shall include but not be limited to: -Active users (identifiable by user id and health system affiliation) -Daily activity reports including: a. Number of messages going through KHIE's HISP b. Active data feeds (with error reporting capability) c. Daily query information (submitted documents, queries performed, returned empty data sets) -Meaningful Use Reporting (monthly) a. For each provider that has submitted a Summary of Care CCD, the system shall log the queries for each Summary of Care CCD that were made by another provider. -System performance metrics (query response time, data feed health monitoring)

13.7 The new KHIE solution shall be configured so that it enables the KHIE staff to filter reports from the dashboard by data feed and provider NPIs.

113

h. Interfaces with other State and Cabinet Systems: Please describe your approach to interfacing with the Cabinet systems as described in Section 50.7.2.13. Include details about:

1) Technical Solution and Architecture 2) Processing granularity, latency 3) Tracking of status and test results 4) Mapping and transformation capabilities 5) Requirements gathering and implementation strategy

Please provide a matrix showing the data feeds that you support as well as the transports. Those required are listed in this RFP; however, the matrix should include all supported.

i. Implementation Project Plan/Testing/Training and Support:

Describe the implementation strategy and technical approach to implementation for the proposed solution. Describe the project management methodology and tools used by your company and examples of all required plans identified in Section 50. Provide a list of EHR vendors/products that are currently connected to the proposed KHIE solution. Please provide the following information regarding system documentation:

1) Indicate if system documentation is available online 2) Indicate how often documentation is updated and how the

updates are provided Please provide the following information regarding your system implementation testing strategy:

1) Describe how the Commonwealth will be able to test the product in a test environment prior to production roll-out.

2) Describe the test scripts that will be created and how the Commonwealth will have access to these test scripts.

3) Describe how the Commonwealth will have an opportunity to parallel test and conduct user acceptance testing.

4) Describe your procedures for user acceptance testing, stress/load testing, and user acceptance signoff.

Please describe your data conversion experience and the capability of your HIE product to import data from various sources for conversion purposes. Please include a data conversion plan and timeline estimate in the project plan. Please provide a description of your plan/approach to initial onboarding conversion for all existing connections. Please include a timeline in the project plan. Describe whether the existing system

114

will remain operational while moving connections, how long it will remain operational, and what internal or external incentives are necessary to ensure the Cost Proposal Timeline is met. Please provide the following information regarding training and training documentation:

1) Indicate how and the length of end user training that is provided.

2) Indicate whether train the trainer is used. 3) Indicate if training documentation is available in hard copy

format 4) Indicate if online training videos are available and the types 5) Indicate if recorded modules are available 6) Indicate if you provide workflow training courses 7) Indicate if you provide quick references 8) Indicate training procedures for system updates in the future

Please provide the following information regarding Go-Live support:

1) Indicate how many Vendor staff will be on-site during ‘Go-Live’ timeframe

2) Indicate the length of time provided for implementation and Go-Live support

3) Indicate the role of Vendor staff during ‘Go-Live’ Please provide the following information regarding post Go-Live Ongoing Training and Support:

1) Describe Vendor support after Go-Live I. Who will be available to answer questions, issues,

and/or training requests? II. If original implementation team, how long before this

level of service is transferred to ongoing support team? III. Will a post Go-Live assessment be completed after a

specified amount of time by the Vendor? Please provide your standard Service Level Agreement (SLA) template. During negotiations with the selected Vendor, CHFS will work with the Vendor to determine any penalties and/or incentives relative to the contract. Please describe your experience migrating existing provider connections. Include estimates for all of the existing KHIE connections provided in this RFP and the strategies for minimizing the time to complete the migration of all connections.

115

j. Ongoing Onboarding/Testing/Training and Support: Please provide a description of your approach to system testing, provider onboarding testing, and ongoing onboarding tracking and improvement. Provide the following information:

1) Describe how software patches, updates, and new releases will be tested in a test environment prior to being move to production.

2) Describe the test scripts and test data that will be created and how the Commonwealth and the provider will have access to these test scripts.

3) Describe the process for moving those items to production and the communications or notifications which are done in advance of that for on-going system changes and upgrades.

4) Describe how provider onboarding testing is done, what tools are available to Offeror staff and what tools are available to KHIE staff. Please demonstrate those tools and capabilities.

5) Describe your procedures for moving each provider through the testing process and what progress information is tracked about each provider at each stage.

6) Stats from the provider testing and onboarding process at other HIE implementations showing such things as the stages tracked by vendor as well as the shortest, longest, and average time to complete the stage.

7) Provide your standard provider onboarding SLAs and supporting information.

Please include a timeline in the project plan. Describe whether the existing system will remain operational while moving connections, how long it will remain operational, and what internal or external incentives are necessary to ensure the KHIE Timeline shown in Figure 1 under 50.7.4 is met. Please provide the following information regarding help desk support:

1) Provide your standard help desk SLAs and supporting information.

2) Describe whether tiered support is implemented and what affect that has.

3) Describe your typical escalation process 4) Indicate whether support is staffed by vendor employees or

contracted. 5) Explain how problems or complaints with help desk

timeliness or courtesy are dealt with. 6) Indicate whether or not there is a self-service portal.

116

7) Please provide the following ongoing support statistics from another implementation: I. # of support calls including the % of resolutions at each

severity level II. % of first call resolutions vs. 2nd and so on.

III. Average time to answer calls and % of drops. IV. Average amount of time for issue resolution

DO NOT INCLUDE ANY COST IN THE TECHNICAL RESPONSE. COST SHOULD BE SUBMITTED SEPARATELY

60.8 Cost Proposal Content

The vendor should provide its costs for the proposed solution as instructed on the Cost Proposal Form. (see Attachment B and Section 50.7.4 Deliverables and Milestones The Commonwealth of Kentucky is Tax Exempt. Do not include Federal Excise Tax, Kentucky Sales or Use Tax in proposed costs.

Costs for developing the proposals are solely the responsibility of the offerors. The Commonwealth of Kentucky shall not provide any reimbursements for such costs.

A proposal shall not be considered for award if the price in the proposal was not arrived at independently without collusion, consultation, communication, or agreement as to any matter relating to such prices with any other offeror or with any competitor. In addition, the offeror is prohibited from making multiple proposals in a different form.

Should conflict of interest be detected any time during the contract, the contract shall be null and void and the contractor shall assume all costs of this project until such time that a new contractor is selected.

Vendor should complete the following certified statement and submit it with the Cost Proposal.

I, ________________________, representing ____________________ (print name) (Company name)

certify that the price in this proposal was arrived without any conflict of interest, as described above.

___________________________________

Signature / Date

117

SECTION 70 – PROPOSAL EVALUATION 70.1 Proposal Evaluation

The Commonwealth shall conduct a comprehensive, fair, and impartial evaluation of all proposals. The Commonwealth may reject any proposal that is incomplete or in which there are significant inconsistencies or inaccuracies. The Commonwealth reserves the right to reject all proposals.

The Commonwealth has established a Proposal Evaluation Committee to review, evaluate and verify information submitted by the offeror.

Each vendor is responsible for submitting all relevant, factual and correct information with their offer to enable the evaluator(s) to afford each vendor the maximum score based on the available data submitted by the vendor. The Commonwealth shall evaluate the proposals by assigning scores as indicated.

70.2 Technical Proposal Evaluation

Technical Proposal Evaluation Criteria Points Possible

Executive Summary, Corporate Background Experience, Proposed Project Team Experience

600

Security Plan, Risk Management Plan, Infrastructure, Disaster Recovery and Redundancy Plan

150

Software Requirements, Interfaces with other State and Cabinet Systems

300

KHIE Functional Requirements 900 Implementation Project Plan/Training/Testing and Support,

Ongoing Onboarding, Training, Testing and Support 1050

Total Points Possible 3000

70.3 Cost Proposal Evaluation

Cost Proposal Evaluation Criteria Points Possible

Implementation Costs 300 Conversion Costs 300

Ongoing Costs 600 Total Points Possible 1200

The scoring of cost is subject to Reciprocal preference for Kentucky resident bidders and Preferences for a Qualified Bidder or the Department of Corrections, Division of Prison Industries (KAR 200 5:410).

118

70.4 Oral Demonstration/Presentation Evaluation, if required Oral Demonstration/Presentation Proposal Evaluation

Criteria Points Possible Demonstration/Presentation, if required

The Commonwealth reserves the right to require Oral Presentations/Demonstrations to verify or expand on the Technical or Cost Proposals. This is the opportunity for the vendor to present and demonstrate the solution and to answer questions or to clarify the understanding of the evaluation committee in accordance with the requirements of this RFP. The Commonwealth reserves the right to reject any or all proposals in whole or in part based on the oral presentations/demonstrations. If required, the top three (3) highest ranking vendors will be invited. Scheduling will be at the discretion of the Commonwealth. The Commonwealth reserves the right to not require oral presentations/demonstrations if they do not affect the final rankings.

1000

Total Points Possible 1000 70.5 Best and Final Offer (BAFO)

In accordance with FAP 111-57-00 (3) (h), the Commonwealth reserves the right to request Best and Final Offers (BAFO).

70.6 Total Proposal Evaluation

Criteria Maximum Points Possible Technical Proposal 3000

Cost Proposal 1200 Oral Demonstrations/Presentations, if

required 1000

MAXIMUM POINTS POSSIBLE 5200

SECTION 80 – NEGOTIATIONS

The Commonwealth reserves the right pursuant to KRS 45A.085 to negotiate a contract with the top-ranked vendor. In the event the Commonwealth cannot reach agreement with the top-ranked vendor, it may proceed to negotiate with the next highest ranked vendor, and so on. It is the Commonwealth’s intent to award a contract to the vendor with whom successful negotiations are completed.

119

Terms and conditions that may be negotiated at the sole discretion of the Commonwealth include but are not limit to issues related to the Technical and/or Cost Proposals.

SECTION 90 – ATTACHMENTS Attachments indicated below may be downloaded by accessing the “Attachment” link found on the solicitation details view page where this RFP was downloaded. Once the Attachment link is accessed, select the file name you wish to download, and select the “Download Attachment” hyperlink. For assistance with downloading these attachments please contact the Commonwealth Buyer.

ATTACHMENT A – This RFP Document ATTACHMENT B – Cost Proposal Form ATTACHMENT C – Affidavits ATTACHMENT D – Vendors’ Question Form ATTACHMENT E – The Protection of Personal Information Security and Breach Investigation Procedures and Practice Act (KRS 61.931)