TECHNICAL SUBMITTAL the final resolution of the cancellation or the termination. The Offeror must...

of 49

TECHNICAL SUBMITTAL

I-1. Statement of the Project. State in succinct terms your understanding of the project

presented and the services required by this RFP. The Offeror’s response should demonstrate that the Offeror fully understands the scope of services to be provided, the Offeror’s responsibilities, and how the Offeror will effectively manage the contract.

Offeror Response

I-2. Management Summary. Include a narrative description of the proposed effort and a list

of the items to be delivered or services to be provided. The Offeror should condense and highlight the contents of the Technical Submittal in a manner that allows a broad understanding of the entire Technical Submittal. Offeror Response

I-3. Qualifications.

A. Company Overview. The Offeror must describe its corporate history and the relevant experience of the Offeror and any subcontractors. This section must detail information on the ownership of the company (names and percent of ownership), the date the company was established, the date the company began operations, the physical location of the company, and the current size of the company. The Offeror must provide a corporate organizational chart.

The Offeror must describe its corporate identity and legal status, including the name, address, telephone number, and email address for the legal entity that is submitting the proposal. In addition, the Offeror must provide the name of the principal officers, a description of its major services, and any specific licenses and accreditations held by the Offeror.

If an Offeror is proposing to use the services or products of a subsidiary or affiliated firm, the Offeror must describe the business arrangement with that entity and the scope of the services the entity will provide. If the experience of any proposed subcontractor is being used to meet the qualifications and requirements of this RFP, the Offeror must provide the same information as listed above for the subcontractor. This information must be presented separately within this section, clearly identifying the subcontractor’s experience and name.

B. References. The Offeror must provide a list of at least three (3) relevant contacts

within the past three (3) years to serve as corporate references. The references must be outside clients (non-DHS). This list shall include the following for each reference: 1. Name of customer 2. Type of contract 3. Contract description, including type of service provided

of 49

4. Total contract value 5. Contracting officer’s name and telephone number 6. Role of subcontractors (if any) 7. Time period in which service was provided The Offeror must submit Appendix B, Corporate Reference Questionnaire, directly to the contacts listed. The references should return the completed questionnaires in sealed envelopes to the Offeror. The Offeror must include these sealed references with its technical submittal under Tab 12. The Offeror must disclose any contract or agreement cancellations or terminations within five (5) years preceding the issuance of this RFP. If a contract or agreement was canceled or terminated for lack of performance, the Offeror must provide details on the customer’s allegations, the Offeror’s position relevant to the allegations, and the final resolution of the cancellation or the termination. The Offeror must include each customer’s company or entity name, address, contact name, phone number, and e-mail address. The Department may disqualify an Offeror based on a failure to disclose such a cancelled or terminated contract or agreement. If the Department learns about such a failure to disclose after a contract is awarded, the Department may terminate the contract. Offeror Response

C. Prior Experience. The Offeror should include experience or similar experience with

implementations similar in size and complexity to the Pennsylvania’s Patient & Provider Network (P3N). Experience includes implementation activities, operations, project management activities, knowledge of Health Information Exchange (HIE), training, testing, and supporting the transition from legacy to new systems. The Offeror should include experience with complete lifecycle support from implementation activities through post-implementation and the Maintenance and Operations phase (“Maintenance and Operations”). Highlight any HIE or healthcare-related experience that your organization performed within the last four (4) years.

Experience shown should be work done by individuals who will be assigned to the Project as well as that of your company. Referenced studies or projects referred to must be identified and the name of the customer shown, including the name, address, and telephone number of the responsible official of the customer, company, or agency who may be contacted.

Offeror Response

D. Offeror Personnel. Include the number of executive and professional personnel,

analysts, auditors, researchers, programmers, consultants, and staff, who will be engaged in the work. Show where these personnel will be physically located during the time they are engaged in the Project. For Key Personnel, defined below, include

of 49

the employee’s name and, through a resume or similar document, the Project personnel’s education and experience in similar in size and scope projects. Indicate the responsibilities each individual will have in this Project and how long each has been with your company. Identify by name any subcontractors you intend to use and the services they will perform.

The Department has identified five (5) Key Personnel: 1. Executive Account Director 2. Project Manager 3. Technical Manager 4. Testing Manager 5. Training Manager The table below provides the minimum qualifications and high-level responsibilities for each Key Personnel.

Table 1: Key Personnel Qualifications Role Name Responsibilities Qualifications

Executive Account Director

1. Provide overall leadership, coordination, and implementation of the P3N. 2. Communicate with Commonwealth executives, other contractors, and organizations who use the P3N, as needed. 3. Act as the responsible party if issues and risks arise that cannot be resolved with the Project Manager. 4. Function as the primary point of contact with the Department executive staff for activities related to contract administration, overall project management and scheduling, correspondence between the Department and the selected Offeror, dispute resolution, and status reporting. 5. Responsible for approving the invoices submitted to the Department.

1. Ability to commit selected Offeror resources as needed to successfully perform work. 2. Ability to identify and resolve project-related issues and risks requiring escalation within the selected Offeror organization. 3. Ability to resolve project-related issues and risks requiring action by subcontractors. 4. Minimum of ten (10) years of experience working on or leading large, complex system implementation projects for similar clients. 5. Knowledge of the Health and Human Service (“HHS”) industry.

Project Manager 1. Provide day-to-day management of the P3N Project. 2. Be the principal liaison for the Executive Account Director, Department Project Manager, Department staff, legacy and other P3N contractors. 3. Guide the project by using project management processes, organizing

1. Minimum of eight (8) years of experience managing large, complex system, and with the development, implementation, and operation of projects of a scale similar to the P3N. 2. Minimum of five (5) years of experience managing design and development of healthcare information exchange (HIE) systems.

of 49

the project, and managing teamwork activities consistent with the approved Work Plan. 4. Schedule and report project activities. 5. Coordinate use of personnel resources. 6. Point of contact for issue identification and resolution. 7. Oversee Disaster Recovery (“DR”) testing. 8. Manage implementation of the P3N, including migration from legacy system and all system change requests. 9. Responsible for all project Deliverables.

3. Experience leading teams of more than twenty (20) staff, including staff from diverse organizations, to successfully implement and operate technology-based solutions. 4. Working knowledge of the Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK) terminology and principles.

Technical Manager

1. Oversee the system development, enhancements, and maintenance, as well as all integration efforts. 2. Manage and ensure all business requirements are met by the technical requirements. 3. Oversee the modification of requirements through the Change Control Board (“CCB”). 4. Function as point of contact for technical infrastructure and platform. 5. Communicate infrastructure details to the Department and other contractors and facilitate all integration efforts from a technical perspective. 6. Provide guidance on decisions related to network, database, interfaces, and integration. 7. Responsible for the DR plan and participating in DR testing.

1. Minimum of ten (10) years of experience in managing technical requirements, configuration management, interoperability, testing, system development, system integration, and release management of large-scale IT implementations. 2. Understanding of technology, data, process/application, and organizational architectures. 3. Experience working across teams comprising multiple stakeholders and organizations to efficiently and effectively deliver technology-based solutions and services. 4. Experience with planning and implementing appropriate hardware, software, and communications upgrades to meet business needs. 5. Have experience troubleshooting issues in complex technology-based solutions. 6. Working knowledge of the ITIL (Information Technology Infrastructure Library) V3 Service Lifecycle.

Testing Manager 1. Coordinate testing efforts for P3N to support implementations, continuity of operations (COOP), and overall function.

1. Minimum of six (6) years of experience with planning and executing all phases of testing – unit testing, system testing, integration

of 49

2. Develop the Test Plan for P3N system modifications and enhancements. 3. Oversee test case and test script development and approval for P3N integration testing efforts. 4. Facilitate test environment setup. 5. Coordinate defect management efforts during integration testing efforts. 6. Participate in DR testing.

testing, user acceptance testing, regression testing, and performance testing. 2. Experience with and expertise in selection and use of automated test tools and other testing-related tools. 3. Experience managing test teams comprising individuals from multiple organizations.

Training Manager 1. Provide internal training to Commonwealth staff and other P3N stakeholders on the P3N system components and functionality. 2. Provide training as needed to communicate framework details, integration items, governance processes, and other project items. 3. Create and maintain training materials related to the P3N. 4. Develop and deliver training materials for the P3N system.

1. Minimum of eight (8) years of experience leading a team responsible for creating training materials and directing training activities. 2. Experience with planning and implementing training activities. 3. Experience working with diverse stakeholders and staff in training efforts. 4. Familiarity with technologies included in Offeror’s proposed solution.

A minimum of three (3) client references for Key Personnel must be identified. All client references for Key Personnel must be outside clients (non-DHS) who can give information on the individual’s experience and competence to perform project tasks similar to those requested in this RFP. Key Personnel may be a member of the Offeror’s organization or any subcontractor included in the Offeror’s proposal. The Offeror must submit Appendix C, Personnel Reference Questionnaire, directly to the contacts listed. The references should return completed questionnaires in sealed envelopes to the Offeror. The Offeror should include these sealed references with its proposal under Tab 13. Submitted resumes are not to include personal information that will, or will be likely to, require redaction for release of the proposal under the Right-to-Know Law, including but not limited to home addresses and phone numbers, Social Security Numbers, Driver’s License numbers or numbers from state identification cards issued in lieu of a Driver’s License, and financial account numbers. If the Commonwealth requires any of this information for security validation or other purposes, the information will be requested separately and as necessary.

of 49

E. Staffing Requirements. The selected Offeror must maintain a core team of qualified staff who are able to support all aspects of the DHS P3N Project, as well as assign additional staff as needed during each implementation phase. The selected Offeror must be able to work cooperatively with Commonwealth staff, legacy system contractors, and other individuals and entities, during the P3N Project. The selected Offeror must coordinate and receive direction from designated Department and Health and Human Services Delivery Center (“HHSDC”) staff. In the case it is necessary to identify a resource who will not be 100% dedicated and full time to this Project, the selected Offeror must indicate the percentage of time the resource will be assigned to the contract and the percentage of time the resource will be assigned to concurrent projects. The selected Offeror may not assign Key Personnel to more than one role or to any other position under the P3N project contract. The selected Offeror may acquire specialized expertise through the use of subcontracts and must identify any proposed subcontractors in response to Part I, Section I-3.G. Subcontractors. For all other personnel, describe job title, position descriptions, responsibilities, and minimum qualifications. The Offeror must include organizational charts outlining the staffing, reporting relationships, and staff members in its response. Show the total number of proposed staff and indicate the Full Time Equivalent to account for any additional staff that are not assigned on a full-time basis. Provide similar information for any subcontractors that are proposed. The organizational chart must illustrate the lines of authority, designate the positions responsible and accountable for the completion of each component of the RFP, indicate the names, if available, job titles, number of personnel who will be assigned to each role, and the number of hours per week each person is projected to work on this project. The organizational chart must clearly indicate any subcontracted functions, along with the name of the subcontracting entities and the services they will perform.

F. Key Personnel Diversions or Replacement. Once Key Personnel are approved by

DHS, the selected Offeror may not divert or replace personnel without prior approval of the DHS Contract Administrator (or designee). The selected Offeror must provide notice of a proposed diversion or replacement to the DHS Contract Administrator (or designee) at least thirty (30) calendar days in advance and provide the name, qualifications, and background check (if required) of the person who will replace the diverted personnel. The DHS Contract Administrator (or designee) will notify the selected Offeror within ten (10) business days of the diversion notice whether the proposed diversion is acceptable and if the replacement is approved. “Divert” or “diversion” is defined as the transfer of personnel by the selected Offeror or its subcontractor to another assignment within the control of either the Offeror or subcontractor. Advance notification and approval do not include changes in Key Personnel due to resignations, death, disability, dismissal for cause or dismissal as a result of the termination of a subcontract or any other causes beyond the control of the selected Offeror or its subcontractor. DHS must approve the replacement personnel.

of 49

The DHS Contract Administrator (or designee) may request the selected Offeror remove a person from this project at any time. In the event a person is removed, the selected Offeror will have ten (10) business days to fill the vacancy with a person possessing the required experience and skills, subject to the DHS Contract Administrator’s (or designee’s) approval. DHS may require the removal of an assigned resource to the contract at any time. Offeror Response

G. Subcontractors: Provide a subcontracting plan for all subcontractors, including SDB

and SB subcontractors, who will be assigned to the Project. The selected Offeror is prohibited from subcontracting or outsourcing any part of this Project without express written approval from the Commonwealth. Upon award of the contract resulting from this RFP, subcontractors included in the proposal submission are deemed approved. For each subcontractor included in your subcontracting plan provide:

1. Name of subcontractor; 2. Address of subcontractor; 3. Number of years worked with the subcontractor; 4. Number of employees by job category to work on this project; 5. Description of services to be performed; 6. What percentage of time the staff will be dedicated to this project; 7. Geographical location of staff; and 8. Resumes (if appropriate and available).

If applicable, the Offeror’s subcontractor information must include (through a resume or a similar document) the employees’ names, education, and experience in the services outlined in this RFP. Information provided shall also indicate the responsibilities each individual will have in this Project and how long each has been with the subcontractor’s company.

Offeror Response I-4. Training. The selected Offeror must develop training materials and deliver training for

system users, and tailor the training to the perspective of the stakeholders, including Department staff and P3N Participants who will interact with the P3N users. The selected Offeror must provide training that will present an understanding of P3N functionality, user interfaces, technical components, reporting, and other operational requirements. The selected Offeror must develop and provide training materials and user assessments to result in users that are proficient in using the new system and are effective in completing their normal business operations and service delivery activities.

The selected Offeror must provide both initial and ongoing training on the use and operation of the P3N. The selected Offeror must develop, monitor, and execute a user training survey to evaluate the training provided and allow for user feedback. The survey must be approved by the Department. The selected Offeror must include a Training Plan as part of its Work Plan. The selected Offeror must account for training during the implementation and Maintenance and Operations phases in its plan. The Offeror must

of 49

describe its training solution, the training schedule, and samples of training material in its Technical Submittal. The selected Offeror also must make training available through off-site training seminars, and virtual technology such as WebEx, or other appropriate remote web conference applications and e-Training courses. Training must be flexible to account for the various P3N stakeholders. The selected Offeror will also include Train-the-Trainer methodology and will make the training content on the Knowledge Base (“KB”) available to Tier 1 P3N Support Center trainers and personnel.

Offeror Response

I-5. Financial Capability. Describe your company’s financial stability and economic

capability to perform the contract requirements. Provide your company’s financial statements (audited, if available) for the past three (3) fiscal years. Financial statements must include the company’s Balance Sheet and Income Statement or Profit/Loss Statements. Also include a Dun & Bradstreet comprehensive report, if available. If your company is a publicly traded company, please provide a link to your financial records on your company website in lieu of providing hardcopies. The Commonwealth may request additional information it deems necessary to evaluate an Offeror’s financial capability. Offeror Response

I-6. Work Plan. Describe in narrative form your plan for accomplishing the work. Use the

task descriptions, deliverables, and reports and project control activities in Part I as your reference point. Modifications of the task descriptions are permitted; however, reasons for changes should be fully explained. Indicate the number of person hours allocated to each task. Include a Program Evaluation and Review Technique or similar type display, time related, showing each event. If more than one approach is apparent, comment on why you chose this approach. Where appropriate, the selected Offeror must use automation to facilitate the completion of tasks. Describe the relationship between key staff described in Part I, Section I-3.D Offeror Personnel and the specific tasks, assignments, and deliverables proposed to accomplish the scope of work. Indicate the number of staff hours allocated to each task.

Describe your management approach, including how it will implement its proposed work plan. Where applicable, the Offeror should provide specific examples of methodologies or approaches, including monitoring approaches, it will use to fulfill the RFP requirements and examples of similar experience and approach on comparable projects. The Offeror should describe the management and monitoring controls it will use to achieve the required quality of services and all performance requirements. The Offeror must also address its approach to internally monitor and evaluate the effectiveness of meeting the agreement requirements. The Offeror should include its planned approach and process for establishing and maintaining communication between all parties and a technical approach that is aligned with all written specifications and requirements contained in the RFP. The work plan must include a timeline with goals and benchmarks for implementation, as well as the Offeror’s understanding of the Department’s vision and scope of the Project. The Offeror

of 49

should also state how the objectives of the Project will be met and how each task will be performed. Offeror Response

I-7. Tasks.

A. Program Management. The Department will provide strategic oversight for the P3N Implementation Project. The selected Offeror has primary responsibility for the services under a resulting contract for the lifecycle of the P3N. Throughout the life of the P3N contract, the selected Offeror must use project management techniques that include a comprehensive project plan that is designed, developed, implemented, monitored, tracked, and maintained. The selected Offeror must develop status reports and project plan updates as defined in Part I, Section I-9, Reports and Program Control. The selected Offeror must develop, maintain, and execute a Master Work Plan for the successful completion of services within scope, budget, and schedule throughout the term of the contract. The Work Plan must adhere to industry best practices for project management including the Project Management Body of Knowledge (“PMBOK®”) and Information Technology Infrastructure Library (“ITIL”) concepts. The Offeror must describe standards that it will use and its rationale for choosing that project management tool. The Work Plan must include the transition from the legacy system to P3N and must be updated as each component is implemented. After the P3N moves into Maintenance and Operations, the selected Offeror will continue the development of the P3N for additional projects as required by the Department. The Selected Offeror will maintain an experienced staff after the implementation of the P3N for supporting and planning of new initiatives that require system changes. The selected Offeror must develop a Work Plan that, at a minimum, includes the following deliverables: 1. Transition 2. Master Schedule 3. Communications Plan 4. Risk and Issues Management Plan 5. Change Management Plan 6. Test Plan 7. Defect Management Plan 8. Release Management Plan 9. Security Plan 10. Quality Management Plan 11. Closeout Plan 12. Maintenance and Operations Plan 13. Support Plan 14. Turnover Plan

of 49

Upon approval by the Department, the selected Offeror must execute and monitor the Work Plan. As changes are approved through the Change Management process, the selected Offeror must update plans and provide the Department with a summary of the changes as part of its reporting requirements. Offerors may recommend an alternative to this reporting requirement and provide a rationale for their recommendation. The selected Offeror must immediately alert the Department to any risk identified as the result of the change. Deliverable: P3N Work Plan The Offeror must describe its approach to designing, developing, and implementing the P3N with recommended timelines for completion of the components. Additionally, the Offeror must describe how it will coordinate and work with P3N stakeholders to execute and monitor the Work Plan. Offeror Response

1. Transition. Transition consists of activities that must take place between the

purchase order effective date and the date the selected Offeror is fully responsible for all contract activities. During the transition from the legacy system, the selected Offeror must interact with the legacy system contractor to maintain ongoing operations of the Department’s programs and facilitate a seamless transition. The Department has designated a maximum of three (3) months for the completion of all transition activities. The primary objectives of the Transition Phase are the following: a. The successful orientation, knowledge acquisition, and operational

independence from the incumbent contractor; b. The smooth transition of responsibilities; c. A complete knowledge transfer and operational understanding; d. The establishment of accurate assessments and strong accountability controls; and e. A mitigation of risk to the Commonwealth, DHS, clients, and taxpayers.

The selected Offeror’s responsibilities are to: a. Prepare and submit a comprehensive Transition Plan within two (2) weeks

of the start of the contract. The Transition Plan will incorporate the activities necessary to turn over the business operations in an orderly manner. The plan must address the resources required for the transition, including those from the Department, incumbent contractor, and selected Offeror. Additionally, the plan will identify the transition objectives and work plan activities on a Gantt chart and document activity time frames and responsibilities. The Transition Plan will be submitted to DHS for final review and approval.

b. Provide a plan for a transition of the on-going business, operational, and

strategic business and policy activities currently being executed by the incumbent contractor.

of 49

c. Provide that knowledge transfer occurs in a manner to enable its staff to confidently assume ownership, and to independently manage the in-scope activities without disrupting business operations or timely delivery of services.

d. Receive the turnover of the operation and management of all in-scope business

functions no later than the end of the transition period. This transition must be planned and managed so that no disruption of service takes place.

The Commonwealth’s responsibilities are to: a. Review, approve, disapprove, or request modification and resubmission of the

Transition Plan and Transition Results report. b. Identify Commonwealth key contacts. c. Provide the selected Offeror with the necessary access to Commonwealth

facilities, personnel, documentation, and other items under its control. d. Provide coordination with and access to third parties, as required. e. Participate in Project Initiation and Setup related discussions. f. Provide agreed-upon levels of active participation (of the business staff,

technical staff, and management, as applicable) in the Transition work sessions. g. Coordinate with the incumbent contractor to ensure that the Transition needs

are understood and can be met. h. Facilitate Department engagement in the Transition process.

Deliverable: Transition Plan. Upon DHS approval of the Transition Plan, the selected Offeror will begin transitioning the business functions and provide the transition progress assessments and status updates. The selected Offeror will coordinate with DHS regarding transition tasks, prioritization issues, and conflicting activities interfering with maintaining and operating daily business. Offeror Response

2. Master Schedule. The selected Offeror must design, develop, implement, and

maintain the Master Schedule that includes each system component, in each phase of the project lifecycle. The Master Schedule must include tasks needed to complete the P3N work in scope, on time, and within budget. The Master Schedule will serve as the P3N baseline schedule, including the transition from the legacy system. The selected Offeror must develop an approach that facilitates collaboration with the P3N stakeholders. The selected Offeror must deliver the initial Master Schedule within thirty (30) calendar days after the purchase order effective date. Modifications to the Master Schedule occurring throughout the project lifecycle must be approved by the Department. Deliverable: Master Schedule. The Offeror must describe its approach to the design, development, implementation, and maintenance of the Master Schedule.

of 49

Offeror Response

3. Communications Plan. The selected Offeror must design, develop, implement, and maintain the P3N Communications Plan, under the guidance of the Department. The Communications plan must specify the methods, key stakeholders, legacy system contractor, and timing the selected Offeror will utilize for communicating with the Department and stakeholders during the implementation phase and ongoing throughout Maintenance and Operations. The selected Offeror must deliver the P3N Communications Plan for the Department’s approval within thirty (30) calendar days after the purchase order effective date. Modifications to the P3N Communications Plan occurring throughout the P3N lifecycle must be approved by the Department. Deliverable: Communications Plan. The Offeror must describe its approach to the design, development, implementation, and maintenance of the P3N Communications Plan. Offeror Response

4. Risk and Issues Management Plan. The selected Offeror must design, develop, implement, and maintain a P3N Risk and Issues Management Plan that applies an industry standard risk management methodology throughout the term of the contract. The selected Offeror must deliver the initial P3N Risk and Issues Management Plan for the Department’s approval within thirty (30) calendar days after the purchase order effective date and must update the Plan weekly. At a minimum, the P3N Risk and Issues Management Plan must include issue identification, tracking, analysis, mitigation recommendations, reporting, and resolution. The Department anticipates that risk and issues are both business and technically oriented with a focus on the technical aspects of the P3N. The selected Offeror must immediately alert the Department of any risk or issue that may jeopardize design, development, implementation, and maintenance of the P3N. Deliverable: Risk and Issues Management Plan. The Offeror must describe its approach to identifying, evaluating, and mitigating risk and issues, as well as the design, development, implementation, and maintenance of the P3N Risk and Issues Management Plan. Offeror Response

5. Change Management Plan. The selected Offeror is responsible for the P3N Change Management Process. The selected Offeror shall provide for change management to include change request tracking, approval process, and communication approach. Offerors should describe their change management approach to include how they plan to identify, evaluate, document, prioritize, categorize, resolve, and close-out changes. The Change Management Process shall be used to manage all system changes to include changes for defect management, system maintenance, and modifications/enhancements.

of 49

The Department has final approval on the priority and scheduling of all changes. The selected Offeror will coordinate Change Management processes in a way that clearly defines the responsibilities of the Department, P3N Participants, and if necessary, legacy system contractors. The Change Management Plan should discuss a process to request and manage changes. The plan must contain a methodology for determining and reporting the level of effort, hours, resources, scheduling, and cost of the change. If the Offeror has a process that is used to determine changes that are incorporated into the product versus those that are determined to be custom, it should be fully explained including the change order process and timeframes. The Department requires documentation to justify cost and schedule changes defined during the change order process. The selected Offeror must design, develop, implement, and maintain a comprehensive Change Management Plan that includes a CCB review of requested changes for each system component or functional area. The selected Offeror will deliver the Change Management Plan within forty-five (45) calendar days after the purchase order effective date for the Department’s approval. Deliverable: Change Management Plan. The Offeror must describe its approach to the design, development, implementation, and maintenance of the Change Management Plan. Offeror Response

6. Test Plan. The selected Offeror and legacy system contractors have varying roles dependent upon the level and objective of the test being conducted. While the Department must approve all test results, tests are conducted by different entities. All tests will be led by the selected Offeror. The selected Offeror must cooperate with the Department to develop a comprehensive testing plan that results in each system component meeting or exceeding the functional, technical, security, and performance requirements, including all auditing requirements and design prior to release. The minimum levels of expected testing are defined below. Offerors may recommend additional levels or strategies and provide a rationale for their recommendation.

a. Unit Testing: Unit testing verifies the configuration/changes/enhancement made

to the P3N are functioning in isolation.

b. Integration Testing: Integration testing verifies the configuration/ changes/enhancements made to the P3N are acceptable when integrated with other functions and components of the P3N. Integration testing is testing of individual software changes when combined and tested as a group with the entire P3N.

c. System Testing: System testing tests end-to-end IT system functionality including interfaces with any Agency, Department, or external system. System

of 49

testing includes assessing non-functional system requirements including security, speed, accuracy, and reliability; and assessing functionality to external interfaces to other applications, including P3N Participant systems.

d. User Acceptance Testing (“UAT”): System users test the software to validate it can handle required tasks in real-world scenarios, according to specifications. UAT shall demonstrate how the P3N meets all business requirements. UAT testing for the P3N will be led by the selected Offeror and performed by the Department and external stakeholders such as P3N Participants and their membership Payer and Provider network. The selected Offeror shall provide a UAT Testing environment as well as business and technical support of UAT including testing coordination, progress monitoring, and reporting. Any defects found in UAT will be resolved prior to promoting finished work into production. Once finished work is promoted to production, production validation testing occur

The levels of P3N testing contain various objectives. Offerors may recommend additional objectives or strategies for the Department to consider. The objectives below are a minimum to be conducted: 1) Regression Testing 2) Performance Testing 3) Stress Testing 4) Usability and Human Computer Interaction Testing 5) Production Validation Testing

The selected Offeror must develop test plans that measure and test the P3N’s ability to function as designed and meet the Department’s business needs. The selected Offeror must deliver test plans fourteen (14) calendar days prior to any testing, including system component enhancement or upgrade. Test cases and scripts must include positive and negative scenarios. The negative scenarios must include stress testing the system with invalid data to validate it is rejected correctly. Test scripts must provide step-by-step instructions for executing test cases, including the expected results.

The selected Offeror must provide and maintain a testing environment separate from all other environments (training, disaster recovery, production). The infrastructure of the testing environment will be a replica of the production environment. As testing is being performed, the selected Offeror must communicate testing status to the Department and appropriate stakeholders. The environments must include an integrated test environment to accommodate testing the successful implementations of P3N system components and technical integration activities. The integrated test environment must allow for end-to-end testing and be capable of a mirror of the production system. The selected Offeror must develop test plans and test summary reports in accordance with industry standards. Plans should outline various parameters, resources, methods, and criteria to fully test the system. The selected Offeror must track defects in the CRM tool.

of 49

The selected Offeror must report the results of testing to the Department, and if applicable, legacy system contractors. The report must identify successes, failures, defects, and deviations of the expected results. The report must also identify risks, issues, and dependencies that could prevent successful implementation. The selected Offeror must provide recommendations for corrective action. The Department will approve the testing deliverables and results. Deliverables: 1) Integration Test Plans and Results. 2) System Test Plans and Results. 3) UAT Test Plans and Results. The Offeror must describe its approach to the design, development, implementation, and maintenance of the P3N Test Plans, Testing, and Test Results.

Offeror Response

7. Defect Management Plan. The selected Offeror must identify and resolve defects

identified during testing as well as during production and after implementation. The selected Offeror must provide overall defect management for the P3N and will develop the Defect Management Plan to identify, track, monitor, and report defects identified during testing and production to the Department. The selected Offeror will have a tool, such as ServiceNow or Team Foundation Server, that tracks and monitors defects. The selected Offeror will manage the CCB, with respect to defect management, throughout the P3N system lifecycle. The Department will determine the severity and priority of defects and will use defect resolution in accordance with the protocols in the chart below. The Severity Level and Definition columns will be used pre-Maintenance and Operations, and the remaining columns will be used post production. During Maintenance and Operations, all columns will be used. Final Resolution indicates a fix has been made, and Reconciliation indicates that any corrupted data or incorrect transactions will be fixed or reprocessed. All defects must be resolved by the selected Offeror without any expense to the Department. The selected Offeror must deliver the initial Defect Management Plan and the initial Defect Management Report within thirty (30) calendar days of the purchase order effective date, and must update the report as defects are identified within one (1) business day. The Defect Management Plan and Report will be reviewed monthly as part of the Monthly Status Report (see Part I, Section I-9.3. of this RFP).

of 49

Table 2. Defect Management Definitions Definition Response

Time Corrective Action Plan

Workaround Time

Final Resolution

Reconciliation*

Crit

ical

P3N is unavailable creating an inoperable state. Users unable to perform routine job functions that are mission critical. Qualifying condition examples include: • Inability to make or accept referrals • Inability to access resource directory • Critical loss or corruption of data that severely impacts users • Any security defect that has the potential to expose Protected Health Information (“PHI”) or Personally Identifiable Information (“PII”). • Any Commonwealth-defined mission critical condition

15 Minutes

1.5 hours

2 hours

1 calendar day

3 calendar days

Maj

or

P3N is creating a serious system functionality loss that requires workarounds. Users are partially incapable of completing their normal functions. Qualifying condition examples include: • Stakeholders that have interoperability must use the system in a stand-alone mode • Reporting or data is inaccurate or delayed • Issue affects large group of users with complicated workaround that could delay services to citizens

1 calendar day

5 calendar days

10 calendar days

30 calendar days

40 calendar days

of 49

Min

or

Moderate system issues where workarounds exist but overall do not affect production. Qualifying condition examples include: • Report is not available but can be generated manually • Issue affects small subgroup of users with uncomplicated workaround • One form of a function is available but not all – can see a report online but cannot print it

1 calendar day

5 calendar days

10 calendar days

30 calendar days

40 calendar days

Cos

met

ic

Inconsequential loss of functionality. Impact to user is slight to unknown. Effect on P3N functions negligible to no impact. Issue cosmetic in nature such as spelling error or branding issue. Qualifying condition examples include: • Report incorrectly named • Minor page layout issue • Help page missing or incomplete

7 calendar days

30 calendar days

N/A

90 calendar days or as mutually agreed upon

As mutually agreed upon

*Data reconciliation - Final Resolution indicates a fix has been made and Reconciliation is that any corrupted data or incorrect transactions will be fixed or reprocessed. Deliverables: 1) Defect Management Plan. 2) Defect Management Report. The Offeror must describe its approach to the design, development, implementation, and maintenance of the Defect Management Plan and Reports. Offeror Response

8. Release Management Plan. The selected Offeror must design, develop, implement,

and maintain the P3N Release Management Plan. The initial implementation and release of the P3N system and transition from the legacy system is addressed in the Transition Plan. The Department, selected Offeror, and legacy system contractor will set release timeframes during initial implementation. After the full implementation of P3N (during Maintenance and Operations), the selected Offeror will work with the Department to determine the release schedule. Release planning will be conducted by the selected Offeror under the Department’s

of 49

strategic guidance via the release planning meeting – see Part I, Section I-9.4 Meetings. The Department must approve a release prior to implementation into production. The selected Offeror will deliver the initial P3N Release Management Plan within thirty (30) calendar days after the purchase order effective date, and will update no later than thirty (30) calendar days prior to any system component, functionality, or product release, with additional updates as required. The Release Management Plan will be reviewed monthly as part of the Monthly Status Report (see Part I, Section I-9.3 of this RFP). The Department will require that individual system component release management plans use the Program Management Plan as the starting point. The selected Offeror must coordinate the Release Management Plan with the Department to ensure operational readiness. The selected Offeror will lead release planning meetings, which will be attended by the Department, appropriate internal and external stakeholders, and the selected Offeror. See Part I, Section I-9.4. Meetings of this RFP. Deliverable: Release Management Plan. The Offeror must describe its approach to the design, development, implementation, and maintenance of the Release Management Plan and Checklists. Any releases planned prior to production rollout should be documented within the Release Management Plan with a description of the contents of the release. The Offeror must explain the process to plan and implement system releases. This should include product releases as well as the release of Department specific changes. Offeror Response

9. Security Plan. The selected Offeror will design, develop, implement, and maintain a

P3N Security Plan. The selected Offeror will maintain compliance with Security Requirements in Part I, Section 8-H of the RFP and with Commonwealth Information Technology Policies in the Terms and Conditions. Additionally, the selected Offeror must maintain compliance with the Third-Party hosting security policy found in Appendix H (Requirements for Non-Commonwealth Hosted Applications/Services), and if cloud storage is used, the Cloud Use case found in Appendix I (Cloud Use Case Questions). The selected Offeror must deliver the initial Security Plan forty-five (45) calendar days after the purchase order effective date. The Security Plan must detail how cyber security measures and HIPAA security measures are built into the proposed solution and include how the measures will keep Pennsylvania’s data secure from cyber data breaches and unauthorized HIPAA violations. The Offeror must provide detailed information regarding its Security Plan. a. Describe the security measures in the proposed solution to prevent system and

data breaches. b. Describe preventative measures, such as policies and procedures, taken to reduce

of 49

the risk of system cyber-attacks and HIPAA violations. c. Provide details of how your solution’s cyber security and risk mitigation plan

prevents cyber data breaches, monitors and identifies cyber data breaches, and rectifies cyber data breaches that occur.

d. Describe the frequency of reviews and updates of the cyber security and risk mitigation plan, including the testing process and frequency.

e. Describe the use of PII and PHI with a description of the types of data that will be collected.

f. Describe the sources of PII and PHI, populations, and transfer and disclosure mechanisms.

g. Provide details about the entities with which the collected information will be shared.

h. Describe the privacy and security standards for business partners and other third parties and the agreements that bind these entities.

i. Provide details regarding incident handling procedures. j. Describe the privacy and security awareness programs and materials for the

Offeror’s workforce.

The selected Offeror must detail in the Security Plan how it will enforce security within the P3N and the selected Offeror’s organization including physical security of hardware, interactions between other systems, identification of individuals who have privileged access, and how data to and from external sources is controlled. The selected Offeror must report all system security incidents and breaches including Cyber intrusions to the HHSDC within fifteen (15) minutes of incident identification regardless of the known scope of the incident. The selected Offeror must report misuse of IT resources and loss or theft of equipment (USB drives, laptops, smartphone etc.) that may contain P3N data, via email, to the HHSDC within one (1) hour of the incident. The selected Offeror must follow incident-handling procedures to document the full scope of the incident, containment, eradication, and recovery, as appropriate to the situation for all incidents. The Department may assess damages for a failure to report any security issues or breach incidents as noted and for a failure to provide sufficient response to any security issue or breach. The Offeror must perform annual risk assessments. Assessments are to be conducted by independent, qualified organizations. Assessments must be in accordance with nationally recognized assessment programs such as the NIST Cybersecurity Framework, HITRUST Common Security Framework (CSF), or Electronic Healthcare Network Accreditation Commission (EHNAC) Accreditation. The Security Plan must be updated at least annually or more frequently if required by HIPAA requirements. Deliverables: 1) Security Plan 2) Annual Security Assessment.

The Offeror must describe its approach to designing, maintaining, and monitoring the P3N Security Plan.

of 49

Offeror Response

10. Quality Management (“QM”) Plan. The selected Offeror must have a quality management and assurance process in place to validate the solution is functioning as expected. The selected Offeror will provide QM services. The following items are subject to QA review: Test Plans and Test Results, and Disaster Recovery Testing and Test Results. The selected Offeror will design, develop, implement, and maintain a QM Plan to maintain quality practices for the lifecycle of the P3N. The selected Offeror shall deliver the initial QM Plan within sixty (60) calendar days after the purchase order effective date. The QM Plan must include, at a minimum: a. Overview of QM activities and tasks to be performed. b. Processes and procedures for conducting QA/QC activities, including

procedures for documenting, resolving, and reporting issues and risks identified during QA/QC activities, or problems that may be identified by the Department.

c. Performance monitoring reviews, measures, and reports. d. Roles and responsibilities of the selected Offeror and subcontractors, if

applicable, in performing QA/QC activities. Deliverable: Quality Management Plan. The Offeror must describe its approach to the design, development, implementation, and maintenance of the QM Plan. Offeror Response

11. Closeout Plan. The selected Offeror must design, develop, implement, and

maintain the Closeout Plan. The selected Offeror shall deliver the initial Closeout Plan within thirty (30) calendar days after the statewide implementation of the P3N. The Closeout Plan closes out implementation and describes any activities associated with the transition to Maintenance and Operations. When the P3N is successfully implemented statewide, the selected Offeror must validate all implementation activities have been completed per the Master Work Plan and all risks, issues, and action items are closed. The selected Offeror shall document any remaining operational concerns with an action plan for mitigating the issues and recommendations for future rollouts to prevent reoccurrence. Deliverables: 1) Closeout Plan. 2) Issue resolution plan for operational issues. The Offeror must describe its approach to the design, development, implementation, and maintenance of the Closeout and Issue Resolution Plans.

of 49

Offeror Response

12. Maintenance and Operations (“M&O”) Plan. The selected Offeror must design, develop, implement, and maintain the M&O Plan to assist the Department in managing the P3N system during Maintenance and Operations. The selected Offeror will prepare a M&O Plan for Department approval no later than thirty (30) calendar days prior to the implementation of each system component or service. The selected Offeror must provide operations and maintenance for the P3N including directory maintenance, network monitoring and onboarding, system/product/application upgrades, operational performance metrics, and performance standards metrics. The P3N must be capable of accommodating deployed system components and services while supporting deployment of new functionality without disruption to business. At a minimum, the M&O Plan must include: a. Maintaining current versions and licenses for all software, hardware, or other

infrastructure. b. Performing necessary upgrades and changes to the P3N and components, if

applicable. c. Performing routine preventative maintenance. d. Providing maintenance and downtime notifications for planned and unplanned

downtime, including when work is completed. e. Collaborating with the Department to create a standard schedule for

maintenance activities. f. Providing support for production both during work hours and outside of

normal business hours, and coordinating with the Department for the level of expected support.

g. Maintaining a support and ticket system that is accessible to the Department and P3N Participants.

h. Determining the severity of defects, responsibility, and resolution timelines. i. Onboarding of new stakeholders. Deliverable: Maintenance and Operations Plan. The Offeror must describe its approach to the design, development, implementation, and maintenance of the M&O Plan.

Offeror Response

13. Support Plan. The selected Offeror will provide initial and ongoing customer

service support, including adequate staffing to support a project of this scope. The following is the expectations of the Commonwealth regarding customer support: a. Provide System Support Services. The selected Offeror must accommodate

telephone and email as modes of communication. b. Offeror support must be provided from within the Continental United States c. Phone, web form, and email support shall be available during the hours

of 49

described below. 1) The selected Offeror shall provide both end user support and system

support during the core hours of 8 A.M. - 5 P.M. EST Monday through Friday. This shall include, but is not limited to, assistance and ongoing support regarding problems and issues, guidance in the operation of the solution, and identification and correction of possible data or system errors.

2) The selected Offeror must have 24x7 system support, which includes, but is not limited to, the identification and correction of possible data or system errors. The 24x7 system support must be live phone, web form, and email support.

d. Notifications. Offerors must describe their notification policies and procedures. Offerors must include policies and procedures for notifications to the Commonwealth, stakeholders, and clients in the event of scheduled maintenance, unscheduled maintenance, emergency maintenance, downtime, system errors, degraded performance, product releases, or other user impacting events. The P3N system shall provide system messages at login to notify users of maintenance or other system events.

Deliverable: Support Plan. The Offeror must describe its approach to the design, development, implementation, and maintenance of the Support Plan.

Offeror Response

14. Turnover Plan. Turnover is defined as those activities that the selected Offeror must perform at the end of the contract term, to turnover service delivery to a successor Offeror or to Commonwealth resources. During the turnover period, the selected Offeror must actively and cooperatively participate with the Department and its incoming contractor, if any. Offerors must submit a draft outgoing turnover plan with their Technical Submittal. The selected Offeror must provide the Department and incoming contractor any and all data, content, files, instructions, processes, and all other items deemed appropriate to successfully transition services and work effort. The selected Offeror should describe how it will transition its processes to the Department and its vendors prior to the expiration or termination of the contract. During turnover, the selected Offeror must ensure that the transfer of services does not impact the Department’s administration of the program, including implementation of any new initiatives or projects. The Turnover Plan must include the proposed schedule, activities, and resource requirements associated with the identified turnover tasks. Three (3) months prior to the end of the contract term, the selected Offeror must implement a DHS approved Turnover Plan.

Deliverable: Turnover Plan.

of 49

The Offeror must describe its approach to the design, development, implementation, and maintenance of the Turnover Plan. Offeror Response

I-8. Requirements.

A. Enterprise Master Patient Index (“MPI”). At the core of the P3N system is an Enterprise Master Patient Index (“MPI”). This patient database is managed by a Patient Identifier Cross-Referencing (“PIX”) Manager. It currently supports the patient feeds from Health Information Organization (“HIO”) participants and Commonwealth agencies. A snapshot of approximate patient volumes, maintained in our legacy P3N MPI from DHS and five of our certified Participants, is as follows: • DHS – 4M Medicaid Recipients • P3N Participant 1 – ~5.5M Patients • P3N Participant 2 – ~4M Patients • P3N Participant 3 – ~800K Patients • P3N Participant 4 – ~4.5M Patients • P3N Participant 5 – ~130K Patients There is an expectation the number of sources that will contribute to the MPI will increase to include new P3N participants joining our program along with citizen demographics from other state agencies.

1. Offeror will provide a description of the proposed MPI, including number of

patients managed nationwide, and capacity versus performance metrics.

2. Offeror will provide analysis results of the proposed MPI that were used to evaluate the performance of matching algorithms and configuration changes to those algorithms. Examples may include sensitivity, specificity, and precision metrics from the Sequoia Project, A Framework for Cross-Organizational Patient Identity Management.

3. Offeror will support new patient registration by manual entry, Patient Identifier Cross-Referencing (“PIX”) feeds, and HL7 Admission-Discharge-Transfer (“ADT”) feeds.

4. Offeror will provide a patient feed endpoint for HL7 ADT feeds, to be used for the P3N ADT forwarding service. Offeror will describe any version limitations using these transaction standards. To ensure synchronicity across patient record sources from the same P3N Participant, the system will recognize the HL7 ADT patient record source as the same as the P3N Participant PIX patient record source.

of 49

5. Offeror will accept patient feeds from state agencies. Describe how these person demographics sources can be used to improve or not improve matching when there may not be any clinical data available for retrieval for that person.

6. Offeror will accept patient data batch loaded into the MPI when new sources become available.

7. Offeror will provide the algorithm, list of attributes, it’s probabilistic and/or deterministic methods, and blocking/scoring used to match patients from multiple sources. Matching algorithm will be configurable and tunable based on what is available from all P3N Participants.

8. Offeror will describe how false negatives are minimized and false positives are avoided.

9. Offeror will address non-uniform attributes across all patient record sources (i.e. PA, Penn., Pennsylvania) and how they will be normalized using national standards.

10. Offeror will increase the number of primary data elements when needed, and incorporate secondary data elements to accurately identify patients. The following demographics may be added to improve matching: Previous last/family name, Middle name or initial, Suffix, Current address, Historical address(es), Phone (including home, business, and cell), and Historical phone(s).

11. Offeror will provide for each P3N connected P3N Participant, a PIX endpoint that can be used for patient registrations, updates, queries, and merges.

12. Offeror will provide for queries for patients registered at the P3N through PIX and Cross-Community Patient Discovery (“XCPD”) transactions. Offeror will describe their system, how it accommodates current transaction standards, and any version limitations.

13. Offeror will provide a web-based tool to allow the manual creation of a patient when the P3N does not currently have an MPI record. This will occur when a patient needs to be added to the P3N for any of the services P3N provides. When manually entering the patient into the P3N, entry fields for required matching attributes are to be provided.

14. Offeror will provide a web-based tool to allow Department staff to tag patients as inactive and to merge and split patients as needed. No clinical data will be available from the P3N on patients tagged as inactive. Merges will occur when it’s determined that two patient records are the same person (false negative), and split will occur when it is determined two patient records that are linked together are not the same person (false positive). Offeror will describe the process necessary when a false positive match between patient records is determined.

15. Offeror will describe the staffing and resource requirements necessary to maintain the MPI, evaluate potential duplicate reports, and merge patient records. Offeror

of 49

will identify how much staff is required to periodically review potential duplicate reports and to manually identify the records to be merged. Offeror Response

B. Provider Directory. The P3N Provider Directory supports management of

healthcare provider information in a directory structure. It is one of the core services currently available at the P3N. This directory is maintained through multiple sources. The primary objective of the P3N Provider Directory is to make information available from regional, state, and national sources, as they are stewards of the most accurate and current data. The legacy P3N Provider Directory receives provider data from the following sources: 1. NPPES: National Individual Providers, Organization Providers, Users working

on behalf of a Provider P3N Updated Quarterly – ~5M records https://npiregistry.cms.hhs.gov/

2. PA Dept. of State: PA Health Care Providers and Pharmacies P3N Updated Monthly – ~1.4M records https://www.pals.pa.gov/#/page/search

3. PA Dept. of Health: PA Health Care Facilities P3N Updated Monthly – ~4.5K records http://sais.health.pa.gov/commonpoc/dohQALocatorcommon.asp

4. PA Dept. of Drug and Alcohol: PA Drug and Alcohol Facilities P3N Updated Monthly – ~2.5K records http://sais.health.pa.gov/commonpoc/Content/PublicWeb/DAFind.aspx

The current P3N Provider Directory distinguishes individual and organizational providers. There is an expectation the number of sources that will contribute to the P3N Provider Directory will increase to include data from connected P3N Participants, other agencies, and DHS. DHS intends to add the all Medicaid Providers to the P3N Provider Directory.

1. Offeror’s Provider Directory will be based on national standards and clearly

delineate individual and organizational providers.

2. Offeror will import, combine, and reconcile multiple P3N Provider Directory source files into one source of truth and present a single record for each provider. Offeror will describe how a provider record will be reconciled if there is conflicting information from multiple sources. This reconciliation is to include provider demographics, specialty vocabularies, and provider locations.

3. Offeror will link providers across sources, where applicable, by key identifiers such as NPI, PA License Number, Medicaid Provider ID, and DEA Number. Each individual provider may have multiple locations and multiple specialties.

of 49

4. Offeror’s P3N Provider Directory will classify, allows searches for, and present providers by type, specialties, demographics, and service locations.

5. Offeror will display provider license information and credentials to a user of the P3N Provider Directory.

6. Offeror will link or associate provider records to other provider records and provider organizations. Additionally, a relationship between provider records, patients, and medical records available from the P3N will be maintained.

7. Offeror will have a publicly available web site to allow the public to look up providers based on the specialty, location, and other attributes that describe the provider in the directory. Attributes may include individual provider gender and language.

8. Offeror will provide the ability for P3N Participants to upload and download from the P3N Provider Directory using APIs. There is an expectation the upload from P3N Participants will contain direct addresses that facilitate trusted communications between providers.

9. Offeror to provide a utility and/or method to identify and reconcile erroneous provider directory data. Offeror Response

C. Patient Portal. The legacy P3N has no Patient Portal. Offeror’s proposed system will include a Patient Portal to align with national initiatives to improve patient access to their medical information. This will allow patients the ability to see all of their health information from all providers making data accessible to the P3N, in a consolidated view. The P3N Patient Portal will also allow citizens access to manage consent decisions, upload advance care planning documents, and gain access to other state related data resources as they become available. The Patient Portal is not intended to be a replacement for patient portals that are currently available to patients from practices, health plans, and P3N Participants.

1. A Patient Portal is required in the Offeror’s proposed system. A self-service

portal will allow citizens access using the same credentials used to access other Commonwealth online services. This will be enabled through the Keystone Login Initiative.

2. Offeror’s Patient Portal will leverage the Keystone Login Initiative to identity-proof and allow citizens access the Patient Portal. In July 2019, Governor Wolf announced the Customer Service Transformation Initiative, which will improve customer service by making it easier for Pennsylvanians to connect with state agencies and services, while protecting their privacy and personal information. Appendix L, Customer Service Transformation contains the requirements of this initiative.

of 49

3. Offeror’s Patient Portal user accounts will be tied to a record within the Master Patient Index. This will allow citizens to review their demographic information for accuracy.

4. Offeror’s Patient Portal authorization and permissions will be managed by a system administrator account. Offeror to describe how users are managed and maintained.

5. Offeror will allow patients to electronically opt-out or opt-back-in health information exchanged across the P3N. This action requires the upload of a form provided by the Department that is registered and stored as a Basic Patient Privacy Consent (“BPPC”) document within the P3N.

6. Offeror will allow consent for patients to explicitly share specific Super Protected Data (“SPD”), HIV, drug and alcohol, and mental health records across providers.

7. Offeror will provide consent management by providing multiple methods of obtaining citizen consent (i.e., email, phone, etc.).

8. Offeror will allow patients to upload and replace advance care planning documents such as Advance Directives, Pennsylvania Orders for Life Sustaining Treatment (“POLST”) and Do-Not-Resuscitate (“DNR”) Orders.

9. Offeror will allow patients to view, download, and transmit their clinical data that is available through P3N, including discrete data (demographics, insurance, medications, allergies, visit history, immunizations, diagnosis, procedures, results data, and Continuity of Care Documents) in a patient friendly format.

10. Offeror will allow patients to view their clinical data in chronological order where the most recent clinical defaults to the top of the list.

11. Offeror will allow patients to view the healthcare providers associated with themselves.

12. Offeror will extend the Patient Portal functionality to mobile accessibility.

13. Offeror will allow easy access to the P3N Provider Directory services for provider lookup.

14. Offeror will allow a messaging center for patient-to-provider messaging to those providers who are using the P3N Provider Portal and through the digital contact information maintained in the Provider Directory.

15. Offeror will have a Patient Portal Users Guide that can be easily accessed from the portal, available for viewing or download.

16. Offeror’s Patient Portal will include activity and audit logs for all site activity and will be accessible to the Department System Administration personnel.

of 49

17. Offeror’s Patient Portal will have a support link, where issues may be reported with any user operation issues. Offeror Response

D. Provider Portal. The legacy P3N Provider functionality is limited to allowing for

viewing of the Provider Directory and access for providers upload consent decision forms (opt-out) for patients. Provider’s user account permissions and authorization are managed through role-based security. Provider access to medical records from the P3N is not enabled. Currently, separate provider user accounts can be issued by The Department or P3N Participants and are required for any P3N Participant or Provider to use the P3N Provider Portal.

1. Offeror’s proposed system will include a Provider Portal. The self-service portal

will allow user access using credentials already given to providers accessing other Commonwealth services (i.e., Medical Assistance Providers using PROMISe™). Organizational providers will access the portal using facility administration contact information.

2. Offeror’s Provider Portal user accounts will allow users to self-register. It will also allow the Department and P3N Participants to issue provider user accounts. Providers may also request to assign delegates.

3. Offeror’s Provider Portal user accounts will be tied to a record within the Provider Directory. This will allow Providers to review their directory records for accuracy of their information, such as their service locations, specialties, contact information, credentials, and licensure status.

4. Offeror’s Provider Portal will accept different types of users to include P3N Participants, the Department staff, delegates, and both representatives from organizational and individual providers. Offeror to describe how users are managed and maintained.

5. Offeror will allow providers, from the Provider Portal, under the approval of their patients, to electronically opt-out or opt-back-in health information exchanged across the P3N. This action requires the upload of a form provided by the Department that is registered and stored as a Basic Patient Privacy Consent (“BPPC”) document within the P3N.

6. Offeror’s Provider Portal will allow the provider or P3N Participant to upload other patient documents to the P3N. These documents may include care plans and advance care planning documents such as Advance Directives, Pennsylvania Orders for Life Sustaining Treatment (“POLST”) and Do-Not-Resuscitate (“DNR”) Orders.

7. Offeror will allow providers to identify and tag patients under their care. Offeror to describe how the Provider Portal will show the list of patient’s individual healthcare providers (Care Teams) associated with the patient.

of 49

8. Offeror’s Provider Portal will allow providers to associate themselves with other individual and organizational providers. Describe how this will be shown within the Provider Portal.

9. Offeror’s Provider Portal will allow access, where applicable, to the Department’s Program areas: a. Office of Mental Health and Substance Abuse Services (“OMHSAS”) b. Office of Long-Term Living (“OLTL”) c. Office of Development Programs (“ODP”) d. Office of Children, Youth, and Families (“OCYF”) e. Office of Medical Assistance Programs (“OMAP”) f. Office of Child Development and Early Learning (“OCDEL”)

10. Offeror’s Provider Portal will allow the Department’s service providers to upload and retrieve clinical data associated with a patient. These include Care/Case Managers, Behavioral Health Providers, Care Coordinators, Service Coordinators, Drug and Alcohol Providers, Licensed Nutritionists, and ODP State Centers.

11. Offeror’s Provider Portal will provide access to 42 CFR Part 2 data after explicit consent from the patient to share that data with that provider.

12. Offeror’s Provider Portal will allow users to setup customized views to filter and retrieve documents of interest. Views can be tied to user specialty (Nutritionist, Cardiologist, Payer, etc.) and can provide a discrete history of medications, labs, radiology reports, etc. This will allow providers to have access to both longitudinal records and current patient data such as medications, encounters, lifestyle, complaints, and hospitalizations.

13. Offeror’s Provider Portal will offer access for non-healthcare providers that offer state and community services.

14. Offeror’s Provider Portal will allow providers to subscribe to be notified from the P3N when their patients had an emergency department or inpatient encounter. This notification can occur through the Provider Portal messaging center.

15. Offeror’s Provider Portal will allow the provider to retrieve records on a patient under their care. This clinical data may include CCD’s, BPPC documents, advance directives, records from the statewide immunization registry, prescription drug monitoring program data, care plans, and relevant data provider supports organizations.

16. Offeror’s Provider Portal will allow easy access to the P3N Provider Directory services for provider lookup and potential referrals.

17. Offeror’s Provider Portal will allow a messaging center for provider-to-provider messaging to those providers who are using the P3N Provider Portal and through the digital contact information maintained in the Provider Directory.

of 49

18. Offeror will provide a Provider Portal Users Guide that can be easily accessed from the portal, available for viewing or download.

19. Offeror’s Provider Portal will include activity and audit logs for all site activity and will be accessible to the Department System Administration personnel.

20. Offerors Provider Portal will have a support link, where issues may be reported with any user operation issues. Offeror Response

E. Accessibility. The selected Offeror’s R&RT must adhere to the following

accessibility requirements:

1. Offeror’s system will support browsers and browser versions currently in use by over 95% of web users. Examples include Internet Explorer, Firefox, Safari, Chrome, and Opera. The proposed solution must adhere to World Wide Web Consortium (“W3C”) recommendations and other standards of interoperability.

2. Offeror’s system will comply with Commonwealth accessibility standards as described in the Information Technology Bulletins (“ITBs”).

3. Offeror’s system will be accessible by various types of mobile devices (ex. iPad, smart phones, etc.) via browser or custom application. Offeror Response

F. Cross-Enterprise Document Sharing (“XDS”) Registry and Clinical Data

Repository (“CDR”). The legacy P3N has a Cross-Enterprise Document Sharing (“XDS”) Registry and Clinical Data Repository (“CDR”). The XDS Registry and CDR are available to all current and new P3N Participants. Only two P3N Participants are currently using the XDS Document Registry and only one of those two are using the P3N CDR to host clinical documents. The remaining P3N Participants maintain their own Document Registries and Repositories that are accessible from the P3N. P3N brokers Cross-Community Access (“XCA”) requests to those participants. The legacy P3N CDR hosts Basic Patient Privacy Consent (“BPPC”) Documents, Advance Care Planning Documents, Care Plans, and Continuity of Care Documents from the PA Department of Corrections (“PA DOC”).

1. Offeror will provide a Cross-Enterprise Document Sharing (“XDS”) Registry and

Clinical Data Repository (“CDR"). Offeror will allow P3N Participants to register, query, and retrieve patient’s clinical documents from the P3N using IHE XDS specifications.

2. Offeror will ensure P3N Participants provide metadata in accordance with attributes defined in the IHE XDS specifications as documents are registered in

of 49

the P3N XDS Registry. Metadata requirements for the Document Registry are referenced in the IHE IT Infrastructure Technical Framework.

3. Offeror to clearly associate within the XDS Registry, providers that supplied the clinical data, the patient, and the clinical data.

4. Offeror will onboard state agencies and Program Areas that maintain EHR systems. These EHR systems will use the P3N CDR to share data with participating P3N Participants. These include the Department of Military and Veterans Affairs (“DMVA”) and Pennsylvania State Hospitals.

5. Offeror’s system will have access to P3N Participant CDRs to retrieve and exchange clinical data with all P3N Participants.

6. Offeror’s system will track and maintain data provenance for ownership, origin, and chain-of-custody of clinical data.

7. Offeror will migrate all data from the existing P3N XDS Registry and Repository to the new system.

8. Offeror to describe clinical document/data types supported and define a naming convention to P3N Participants in order to clearly show the type of document/data available for retrieval.

9. Offeror will make available to P3N Participants to share with their membership, data that may be available within the Department such as: Medical Assistance (“MA”) claims data (837s), Social Determinants of Health (“SDOH”) data, Care Plans from MA Care Managers, Obstetrical Needs Assessment (“OBNA”) forms, access to the Resources and Referral Tool, and the Department’s Electronic Visit Verification (“EVV”) system.

10. Offeror will work will all data providers to ensure document content and structure is validated against national standards.

11. Offeror will host structured and unstructured document types within the P3N. Documents may be on-demand or stable documents. The Offeror will provide both discrete and clinical summary documents. The Offeror’s system will provide the capability to serve up individual discrete documents and a single longitudinal record from all P3N structured clinical data sources, that has been aggregated, code set normalized, and deduplicated.

12. Offeror will allow P3N Participants to execute targeted queries against the P3N for aggregated and discrete clinical data. Specific types of data include C-CDA R2.1 template documents, consent decision documents, lab results, radiology reports, and any other type documents represented in the metadata of both the XDS registry and query messages to the P3N.

13. Offeror will allow a targeted query that will produce a medication list.

of 49

14. Offeror will allow P3N Participants to execute targeted queries against the P3N that represent Payer queries, which will exclude clinical data associated with self-pay encounters in the query response.

15. Offeror to describe how clinical data associated with a self-pay clinical data is available to the P3N for healthcare providers but is not made available to Payers connected to P3N Participants.

16. Offeror to provide a dashboard that reflects the contents of the XDS Registry and CDR. Offeror Response

G. System Connectivity. The legacy P3N offers multiple connectivity options to P3N

Participants and state agencies. P3N Participants and state agencies that make clinical data available to the P3N connect via IHE and HL7 interfaces. The HL7 interface used by P3N Participants for the P3N ADT service is described in the ADT Forwarding Service section of this document. State agencies that supply provider data for import into the P3N Provider Directory do so via sFTP. Patient feeds provide for registration, update, and merge. The legacy P3N brokers XCA query and retrieve requests to all connected P3N Participants. This allows P3N Participants to host clinical data within their own repositories with the need to populate the P3N CDR. The legacy P3N does not include an XCPD initiating gateway. All patient clinical data requests rely on knowing where matching patients exists from the P3N Participant PIX feeds. Statewide Connectivity. To summarize the query and retrieve connectivity options available to P3N Participants using IHE specifications: • PIX feed (ITI-8, ITI-44), PIX Query (ITI-9, ITI-45), XDS Query (ITI-18), XDS

Retrieve (ITI-43) • PIX feed (ITI-8, ITI-44), PIX Query (ITI-9, ITI-45), XCA Query (ITI-38), XCA

Retrieve (ITI-39) • PIX feed (ITI-8, ITI-44), XCPD Query (ITI-55), XCA Query (ITI-38), XCA

Retrieve (ITI-39)

1. Offeror will provide all the current connectivity options available to the P3N.

2. Offeror will provide all the XCA brokering capability that exists within the legacy P3N. Brokering is defined as XCA document queries from P3N Participants being forwarded to other P3N Participants providing an aggregated list of documents that a provider can choose from for retrieval.

3. Offeror will provide a means for the Department to easily maintain what connecting P3N Participant connects to which other P3N Participant.

4. Offeror’s system will maintain Audit Trail and Node Authentication (“ATNA”) logs for all IHE transactions.

of 49

5. Offeror’s system will include data provenance carried with clinical data exchange to show what provider created and updated the information and who was the recipient of the data.

6. Offeror will lead and collaborate with the Department to enable the new P3N to be a Qualified Health Information Network (“QHIN”) as defined within Trusted Exchange Framework and Common Agreement (“TEFCA”). As a QHIN, the P3N will be able to access other nationwide networks.

7. Offeror will lead and collaborate with the Department to ensure health information exchange with Pennsylvania’s contiguous states, the Department of Veterans Affairs, U.S. Department of Defense, and other exchange networks.

8. Offeror’s system will provide Fast Healthcare Interoperability Resources (“FHIR”) Application Programming Interfaces (“APIs”). Describe the FHIR version and resources available from the Offeror’s system.

9. Offeror’s system will enable mobile app integration using the SMART on FHIR standard. Offeror Response

H. Security. The P3N requires handling and exchange of Protected Health Information

(“PHI”). Some PHI requires additional protections due to being classified as Super Protected Data (“SPD”) or restricted due to the patient electing to pay for services out-of-pocket and restricted self-pay. The selected Offeror must provide for the protection and confidentiality of all results, records, and other related information. The legacy system allows current P3N Participants to connect and exchange PHI using IHE specifications. All IHE connections use TLS 1.2 mutual authentication. All external data provider and consumer production connections require IP addresses to be whitelisted. A VPN connection is used to connect to the P3N HL7 Admission-Discharge-Transfer (“ADT”) Forwarding Service. All production digital certificates are signed by a Trusted Certificate Authority. All source and consume internet addresses are whitelisted. The Offeror must describe their product’s security features and procedures used to save, store, and secure data at all times, and meet the following requirements: 1. Offeror’s system will provide the same or exceed information security exchange

methods of the legacy P3N.

2. Offeror’s system will encrypt data in transit and at rest.

3. Offeror’s system will align with HIPAA and comply with all Commonwealth IT Security policies, per the contract terms and conditions for information handling and sharing of confidential and sensitive information being transferred from other agencies, external systems, and end users.

of 49

4. Offeror’s system will demonstrate an understanding of and ability to comply with applicable federal and state laws, regulations, and rules regarding the security and confidentiality of information pertaining to state and federal programs and other related health care programs.

5. Offeror will implement and maintain measures to prevent unauthorized access, copying, and distribution of information over the life of the contract.

6. Offeror will provide for proper disposal (i.e., shred, surrender) of both hard and electronic working copies of sensitive information during work on this project, as well as any remaining information upon the completion of the project.

7. Offeror will perform secure code review and web application vulnerability scanning prior to release of any internet-facing features.

8. Offeror will address any security requirements of stakeholder organizations. Offeror Response

I. System Administration. The legacy system has a system administration console

allowing user role-based access to the system portal and features such as the provider directory, consent management, patient merges and splits, and audit logs. There is also a hierarchical system administration capability allowing administration assignment and restriction to patients within their membership. 1. Offeror will provide a P3N System Administration Users Guide.

2. Offeror will provide P3N Systems Administration for user access to the Offeror’s

system portals. This will be a responsibility of the Department, and all user accounts and passwords are subject to Department policies.

3. Offeror will provide identity management (i.e., userid and password requirements) that complies with Commonwealth IT standards.

4. Offeror’s system will allow role-based user access where each user is assigned a role with defined rights to create, read, update, or delete select information based on their role. Offeror’s system will ensure users only access information they are authorized to access.

5. Offeror’s system will provide user provisioning policies on activating and terminating users.

6. Offeror’s system will provide the capability to assign privileged user roles and a method to track activity performed by privileged users.

7. Offeror’s system will provide audit trails and the information collected in those audit trails for data as determined by the Department.

of 49

8. Offeror’s system will provide the capability to mask data (e.g., portions of SSN so only necessary portions of the data can be seen).

9. Offeror’s system will utilize modern authentication methods such as Open ID or SAML.

10. Offeror’s system will provide multi-factor authentication at a minimum for users who appear to constitute a security risk. Offeror Response

J. Consent Registry. Pennsylvania is an opt-out state. Healthcare records are available

to all Providers that have a treatment relationship with a patient unless the patient opts-out. The legacy P3N hosts, within its XDS Registry and CDR, Basic Patient Privacy Consent (“BPPC”) documents that reflect if a patient has opted-out. When a provider queries the P3N via a P3N Participant for patient records, and a patient has opted-out, the only document available from the P3N is the BPPC document. The patient is required to sign a form, which is scanned into the system by the Department, registering the opt-out. P3N Participants can also register BPPC documents to the P3N XDS Registry and CDR through P3N XDS endpoints. The Department is then required to follow-up and correspond with the patient on the consent decision. The patient can opt-back-in to the P3N using the same process.

1. Offeror’s system will provide the opt-out consent registry functionality available

in the legacy P3N.

2. Offeror’s system will provide an enhanced, granular, consent registry, allowing patients, after making an informed decision, to explicitly share clinical data classified as Super Protected Data (“SPD”), from one healthcare provider to another.

3. Offeror’s system will accommodate the explicit, written information about the consent, the permissible use, who you can share this information with, the date, and whether there is an expiry period. Offeror Response

K. Super Protected Data (“SPD”) Tagging and Filtering. Participants in the legacy

P3N do not share clinical data that is considered SPD. They filter clinical data out from exchange using code lists that identify SPD in diagnosis, treatment, lab results, and medications. The only method the legacy P3N uses to manage SPD is allowing P3N Participants to register documents that contain SPD by assigning a confidentiality code of “N” in the metadata with the registry. If the value is something other than “N”, the entire document will not be available for exchange. “N” is defined as privacy metadata indicating that the information is typical, non-stigmatizing health information, which presents typical risk of harm if disclosed without authorization. The legacy P3N does not provide the capability to share clinical data tagged with confidentiality codes other than “N”.

of 49

1. Offeror’s system will accommodate the legacy P3N’s model to require clinical

documents within the CDR to be tagged in the XDS Registry with the letter “N” when there is no SPD present in the document available for retrieval.

2. Offeror’s system will provide a service that can be enabled or disabled, that will filter out SPD data in messages in transit across the P3N. The SPD code lists were created from a workgroup of P3N Participants and will be provided to the selected Offeror for implementation.

3. Offeror’s system will allow SPD to be exchanged, from one healthcare provider to another, given explicit consent was provided by the patient in the Offeror’s enhanced consent registry. Offeror Response

L. Admission-Discharge-Transfer (“ADT”) Forwarding Service. The legacy P3N

hosts an ADT forwarding service that allows P3N Participants to send notifications to subscribing Members if their patients are treated outside their home area. The ADT service matches patients identified at the P3N MPI from the source P3N Participant to patients registered at destination P3N Participants and routes ADTs in near real-time from one Participant to others that have patients registered within the P3N. Secure VPN HL7 TCP destination endpoints are used by the P3N and P3N Participants to receive ADTs. Only HL7-based ADT version 2.x transactions for patients sent to P3N are forwarded to P3N Participants. Transaction logs are maintained and weekly message traffic activity is reported. 1. Offeror’s ADT Service will be fully integrated with the P3N. Patients,

encounters, and providers associated with ADT messages will be associated with patients and providers hosted in the P3N MPI and Provider Directory, respectfully.

2. Offeror’s system will provide the same ADT forwarding functionality currently available to the P3N.

3. Offeror’s system will not allow for the exchange of ADTs if the patient has opted-out of the P3N.

4. Offeror’s system will have the capability to forward ADTs that have specific ICD10 codes that may identify neglect or abuse, exposure to substance abuse, children at risk for elevated lead levels, maternal depression, and developmental delays.

5. Offeror’s ADT service will not allow messages to be exchanged that include SPD data unless the patient explicitly consented to share it through the enhanced Consent Registry.

of 49

6. Offeror to describe how ADTs associated with a self-pay encounter can be filtered out if clinical data is made available to Payers, including Medicaid, from the P3N.

7. Offeror’s system will log all ADT transactions received and forwarded.

8. Offeror’s system will capture the transaction data within the ADT (Patient Class, Admission Source, Diagnosis, etc.) for analysis and reporting.

9. Offeror’s system will forward ADTs to the Department’s Program areas that have a need to monitor and track transition of care. Offeror Response

M. Clinical Data Push Capability. The legacy P3N offers no clinical data push or

directed exchange capability. The Department intends to have the P3N participate as a Trusted Exchange Framework and Common Agreement (“TEFCA”) Qualified Health Information Network (“QHIN”). As a QHIN, there is an expectation that in addition to a query model, there are push services. An example of push services includes patient generated health data.

1. Offeror will perform all work necessary to qualify the P3N as a QHIN.

2. Offeror’s system will have the capability to deliver a patient’s medical records to

one or more specific QHINs using push technology. 3. Offeror will detail its clinical data push capability and associated use cases using

Cross-Community Document Reliable Interchange (“XCDR”), Cross-Enterprise Document Reliable Interchange (“XDR”), or a combination of both specifications. Offeror Response

N. Public Health Gateway (“PHG”). The Department currently hosts a Public Health

Gateway allowing certified P3N Participants to submit data to and query from certain public health reporting registries. The PHG infrastructure and capability are independent of the legacy P3N. The PHG provides a single connection for P3N Participants to connect to the state, reducing the number of direct-connect connections, thus reducing maintenance costs and points of failure. The PHG allows providers that are connected to a P3N Participant to submit information to, and in some cases retrieve information from, six public health reporting systems: • Pennsylvania Cancer Registry (PCR) • Pennsylvania Electronic Lab Reporting (ELR) • Pennsylvania Statewide Immunization Information System (PA SIIS) • Pennsylvania Prescription Drug Monitoring Program (PDMP) • Pennsylvania Syndromic Surveillance • DHS Electronic Clinical Quality Measures (eCQM)

of 49

PHG connections to PA SIIS are bi-directional (submit and query) and the PDMP is query-only.

1. Offeror’s PHG will provide a single connection point as the legacy PHG.

2. Offeror’s PHG will be fully integrated with the P3N. Patients and providers

associated with public health reporting messages and queries will be associated with patients and providers hosted in the P3N MPI and Provider Directory.

3. Offeror’s PHG will be required to support the current security requirements necessary for P3N Participants to connect and deliver messages to the PHG.

4. Offeror’s PHG will allow a query to the P3N to return immunization and PDMP records, through P3N Participants, in the query response to authorized, querying providers.

5. Offeror’s PHG will provide connectivity to the two nationwide PDMP hubs: PMP Interconnect (“PMPi”) and RxCheck.

6. Offeror’s PHG will be required to provide the current security requirements necessary for P3N Participants to connect to the PHG.

7. Offeror’s PHG will have the ability to scale-up in support of new registries. Offeror Response

O. Data Analytics and Reporting. There are no self-service tools that can be used by

the Department for data analytics within the legacy P3N system. Analytics relates to the process of discovering and communicating the meaningful patterns that can be found in the data. It requires data capture, measurement, and analytics beyond the scope of administrative data feeds currently part of system operations. Analytics involves studying past historical data to research potential trends and to analyze the effects of certain decisions or events.

1. Offeror’s system will provide analytics service. This capability will collect

metadata about both the data stored in the P3N XDS Registry and CDR and all messages and data passing through the P3N, including public health reporting.

2. Offeror’s system data analytics service will be used to provide risk scoring and population health management.

3. Offeror’s system data analytics service will include predictive analytics and a visualization tool.

4. Offeror’s system data analytics service will be available to the P3N Participant community.

5. Offeror’s system data analytics tools and capability will not degrade performance of the operational system.

of 49

Offeror Response

P. Quality Reporting for Payers. There are no Payers connected directly to the legacy

P3N. P3N Participants have Payer Members within their individual networks. The intention of this new P3N service is to further enable P3N Participants to support their Payers, with data required for quality reporting. Payers are responsible for completing Quality Assurance Reporting Requirements (“QARR”), including the Health Effectiveness Data and Information Set (“HEDIS”). The clinical data Payers collect for these purposes supports and augments reporting for value-based initiatives.

1. Offeror’s P3N Quality Reporting service will leverage the P3N CDR and captured

metadata on messages that pass through the P3N.

2. Offeror’s P3N Quality Reporting service can also leverage P3N Participant CDRs, given data use agreements cover such usage.

3. Offeror’s P3N Quality Reporting service will be made available to participating P3N Participant community. Data will be made available to support HEDIS reporting and augment reporting efforts for value-based initiatives.

4. Offeror’s P3N Quality Reporting service will, for a specific panels of patients, provide access to data supporting HEDIS and QARR requirements for health plans, as well as provider-level assessment.

5. Offeror’s P3N Quality Reporting service will not allow self-pay data to be available to Payers.

6. Offeror’s P3N Quality Reporting service will make Medical Assistance (“MA”) Claims data available to P3N Participants and Managed Care Organizations (“MCOs”). Offeror Response

Q. Disaster Recovery. The selected Offeror must develop and document a DR plan for

approval by the Commonwealth that integrates with the Commonwealth’s enterprise DR standards and timing objectives for electronic records, equipment, and files relating to DHS support for each line of business. The DR plan shall include at a minimum: 1. The ability to return to full operation within three (3) calendar days of a DR event. 2. A plan to confirm the post-disaster software version is the same as before the

disaster. 3. A procedure to confirm pre-disaster data is not lost or corrupted. 4. Upon installation of any software (new or upgraded), a complete backup copy of

the software must be made; then, the resultant backup must be stored at an external, secure site.

5. The plan must identify the backup sites. Data backups must be captured daily and must be cycled on a weekly basis.

of 49

6. Servers must be connected to an Uninterrupted Power Supply (“UPS”) system, which will condition incoming power to the server and provide sufficient processing time for the server to be correctly shut down in the event of a power failure.

7. In the event of damage of a sufficient magnitude to the primary operational site, an alternate company location, at least fifty (50) miles away, must be modifiable to accommodate the system.

8. The DR plan must include a description of the chain-of-communication and chain-of-command, by level, in preparation for a system or power failure.

9. The selected Offeror must have a Business Continuity Plan to mitigate complete disruption of services (to maintain business operations in a semi-automated or manual mode) until systems have been restored to normal operating capacities.

The selected Offeror must deliver a DR Plan within sixty (60) calendar days after the purchase order effective date and must update the DR plan annually. The DR Plan will be reviewed at a frequency to be determined by the Department.

Deliverable: DR Plan.

Offerors must describe how, by whom, and how often their DR plans will be tested. Offerors must also describe the approach to backing up the infrastructure to provide continuity of operations.

Offeror Response

R. Emergency Preparedness. To support continuity of operations during an emergency,

including a pandemic, the Commonwealth needs a strategy for maintaining operations for an extended period of time. One part of this strategy is to ensure that essential contracts that provide critical business services to the Commonwealth have planned for such an emergency and put contingencies in place to provide needed goods and services. 1. Describe how you anticipate such a crisis will impact your operations. 2. Describe your emergency response continuity of operations plan. Please attach a

copy of your plan, or at a minimum, summarize how your plan addresses the following aspects of preparedness: a. Employee training (describe your organization’s training plan, and how frequently

your plan will be shared with employees) b. Identified essential business functions and key employees within your

organization necessary to carry them out c. Contingency plans for:

i. How your organization will handle staffing issues when a portion of key employees are incapacitated

ii. How employees in your organization will carry out the essential functions if prevented from coming to the primary workplace

d. How your organization will communicate with staff and suppliers when primary communications systems are overloaded or otherwise fail, including key contacts, chain of communications (including suppliers), etc.

e. How and when your emergency plan will be tested, and if the plan will be tested by a third-party

of 49

Offeror Response

S. Applicable References and Policies. The selected Offeror’s system must align with,

and comply when applicable, with the following references and policies: 1. Department’s website for the PA eHealth P3N Participant certification program:

https://www.dhs.pa.gov/providers/Providers/Pages/Health%20Information%20Technology/HIO-Connection.aspx

2. Trusted Exchange Framework and Common Agreement (TEFCA): https://www.healthit.gov/topic/interoperability/trusted-exchange-framework-and-common-agreement

3. U.S. Core Data for Interoperability (USCDI): https://www.healthit.gov/isa/us-core-data-interoperability-uscdi

4. The selected Offeror must comply with all applicable Department and Office of Information policies, including the following: a. Department Policies: https://www.dhs.pa.gov/providers/Providers/Pages/Business%20and%20Tech%20Standards/Security-Domain.aspx b. Office of Information Technology Policies: http://www.oa.pa.gov/Policies/Pages/itp.aspx Offeror Response

T. HIPAA Requirements and Security Breaches. The selected Offeror must operate in

compliance with all applicable HIPAA requirements, including 45 C.F.R. Parts 160 and 164 (Security and Privacy). The selected Offeror must train all personnel in HIPAA requirements and require that they sign a confidentially agreement prior to being granted access to Protected Health Information (“PHI”) and Personally Identifiable Information (“PII”). The selected Offeror must comply with the Business Associate Addendum (Appendix D) located in the Buyer Attachment section. A security breach is an unauthorized access to data, which may include access to provider or beneficiary information, or a loss of media where provider or beneficiary information may be stored, such as a workstation, server, laptop, mobile devices, Universal Serial Bus drives, and files. As soon as a potential HIPAA violation or security breach is identified, the selected Offeror must complete and submit a Security Incident Report to the DHS P3N Project Manager and the Department’s Chief Security Officer. The selected Offeror must report the following: 1. Date and time of the incident 2. Date and time the incident was discovered 3. Name and position of person who discovered the incident 4. How the incident was discovered 5. Description of the incident and the data involved - Include specific data elements if

known, including whether the information was encrypted or protected by another means.



https://www.healthit.gov/topic/interoperability/trusted-exchange-framework-and-common-agreement

https://www.healthit.gov/topic/interoperability/trusted-exchange-framework-and-common-agreement

https://www.healthit.gov/isa/us-core-data-interoperability-uscdi

https://www.dhs.pa.gov/providers/Providers/Pages/Business%20and%20Tech%20Standards/Security-Domain.aspx

https://www.dhs.pa.gov/providers/Providers/Pages/Business%20and%20Tech%20Standards/Security-Domain.aspx

http://www.oa.pa.gov/Policies/Pages/itp.aspx

of 49

6. Potential number of data records involved - If unknown, provide a range (if possible). 7. Location where the incident occurred 8. Information technology involved (e.g., desktop, laptop, email, server, mainframe)

The DHS Contract Administrator must make reports to state and federal authorities as applicable.

Offeror Response

U. Lobbying Certification and Disclosure of Lobbying Activities. This Project may be funded, in whole or in part, with federal monies. Public Law 101-121, Section 319, prohibits federal funds from being expended by the recipient or by any lower tier sub-recipients of a federal contract, grant, loan, or a cooperative agreement to pay any person for influencing, or attempting to influence a federal agency or Congress in connection with the awarding of any federal contract, the making of any federal grant or loan, or entering into any cooperative agreement. All parties who submit proposals in response to this RFP must sign the Lobbying Certification Form, as shown in Additional Required Documentation Group 2.1 No. 2.1.X Lobbying Certification and Disclosure Form and, if applicable, complete the “Disclosure of Lobbying Activities” form. The signed form(s) must be included in the Technical Submittal. The selected Offeror must operate in compliance with all applicable HIPAA requirements, including 45 C.F.R. Parts 160 and 164 (Security and Privacy). The selected Offeror must train all personnel in HIPAA requirements and require that they sign a confidentially agreement prior to access to Protected Health Information (“PHI”) and Personally Identifiable Information (“PII”).

Offeror Response

I-9. Reports and Program Control. The selected Offeror is responsible for the accuracy of

calculations and completeness of data used as input. The selected Offeror must make all defined reports available online and in the required format by the scheduled time as defined and mutually agreed upon.

A. P3N System Dashboard. The selected Offeror must develop a P3N dashboard to report

overall status of the system. The Department will approve the dashboard and standards. This dashboard, at a minimum, will show the following: 1. List all interface connections to the P3N and activity 2. Indicators and alert when a connection goes off-line 3. Indicators and alert when there’s no activity on the connection over a specified

timeframe 4. Availability of active, connected P3N Participants 5. Message types to and from the P3N

Offeror Response

B. System Activity Reports. The selected Offeror, at a minimum, will provide the same

P3N operations reports currently available to the Department: 1. P3N Fill Rate - shows a total count for each patient demographic at the P3N, from

each patient feed, monthly 2. P3N Linking Rate - shows the count of patients in the P3N, from each source, and

of 49

matching rates across the P3N, monthly 3. P3N Opt-Out - shows any patient opt-out, opt-back-in activity, daily 4. P3N Potential Duplicate Patient - shows the total count of near patient matches,

monthly 5. P3N SLA Metrics - shows how the P3N is performing against the SLA metrics,

monthly 6. P3N State Report By HIO - shows a count for the values in the state demographic

field, from each P3N Participant, monthly 7. P3N State Report General - shows a total count for the all values in the state

demographic field, monthly 8. P3N Zip Code By HIO Report - shows all zip code values, in the zip code

demographic fields, per P3N Participant, monthly 9. PHI_CompareIHEandHL7data 10. P3NOptOutNearMatches - shows near matches on patients that have opted-out of the

P3N, monthly 11. PIX Validation Report - shows missing demographics, for each PIX source, weekly 12. PIXLastTransactionsByType - shows PIX registrations, updates, and merges received

from each P3N Participant, weekly 13. Weekly ADT Report - shows all the ADT messages types, sources and destinations,

for the P3N ADT service Offeror Response

C. Monthly Status Reports. The selected Offeror will submit an electronic monthly status

report aligned to the implementation in a format approved by the Department. The selected Offeror must submit monthly reports for the previous month (1st calendar day through the last calendar day of the month) to the Department no later than noon on the fifth business day of the subsequent month. At a minimum, monthly status reports must contain the following: 1. A description of the completion status of the project in terms of the approved project

plan 2. Key Project Indicators, including project scope, schedule, and budget with

explanations if either are beyond thresholds 3. Updated Master Schedule with upcoming milestones and overall percentage complete 4. A dashboard that shows the overall status of the project 5. The plans for activities scheduled for the next month 6. The status of Deliverables as defined in Part I, Section I-7, Tasks 7. Time ahead or behind schedule for applicable tasks 8. Updated issue management report 9. A risk analysis of actual and perceived problems along with suggested mitigations 10. Changes in Key Personnel 11. Key activities completed during the reporting period 12. If the month is the last month of a Phase, the Offeror must provide an end of phase

section outlining accomplishments and achievement of requirements.

The Offeror must describe its approach to and execution of the monthly status reports. The Offeror may propose additional or more frequent reports and report items based on its experience with IT projects of this size and scope. The Offeror must provide a sample monthly status report with its Technical Submittal.

of 49

Offeror Response

D. Meetings. During the course of the contract, the selected Offeror must attend or lead

meetings as requested by the Department. At the Department’s discretion, these meetings will take place in the Harrisburg, Pennsylvania area or be conducted via conference calls. The selected Offeror must attend P3N meetings as directed and support these meetings by providing reports, participating in brainstorming and planning activities, providing consultation and technical assistance, and helping to resolve issues. For meetings lead by the selected Offeror, the selected Offeror must produce meeting materials, which include schedules, written status reports, draft and final minutes, decision registers, agendas, recaps, and other meeting materials. The selected Offeror will:

1. Schedule meetings and locations. 2. Distribute agendas at least two (2) business days prior to meetings. 3. Report on the health of the project via a dashboard. 4. Submit meeting minutes to the Department for approval within two (2) business days

after meeting being held. 5. Review available project artifacts prior to any meeting. 6. Maintain meeting materials in the selected Offeror’s Project Artifact Library.

At a minimum, the selected Offeror must participate as directed in the following meetings:

1. P3N Kick-off Meeting. The selected Offeror must conduct a kick-off meeting for

the stakeholders confirming project scope and objectives, summary of the project, project schedule, methodology, the roles, responsibilities and expectation of the team, and milestones of the P3N system.

2. System Component or Service Kick-Off. Kickoff meetings must be held with the initiation of each new system component or service, cohort of components, or new initiatives. The scope will be limited to the component or service or initiative being released. The meeting will confirm the scope and objectives, schedule, methodology, the roles, responsibilities and expectation of the team, and milestones of the project. The meeting must include the key stakeholders. The selected Offeror will participate in each System Component or Service Kick-Off meeting.

3. Change Control Board Meeting. The selected Offeror will facilitate the CCB Meetings, which include the Department, the selected Offeror, and other P3N system component and legacy system contractors. The CCB reviews defects and requested changes for each system component or functional area and ensures that DHS and the contractors have a mutual understanding of what is to be delivered, when it is to be delivered, and the cost impact in effort hours, if applicable. The CCB serves as a clearinghouse for all defects and changes, including changes to scope and cost. The CCB reports to the

of 49

Department leadership. If a change control item must be elevated above the CCB for resolution, it will be sent by the CCB to the Department leadership for decision. The CCB will meet on a frequency and at a time mutually acceptable to all stakeholders. The CCB is comprised of Department resources from multiple program offices and the contractors who have the authority to make decisions related to the defect or status of a change order, its financial impact, and its importance. The core membership of the CCB will invite subject matter experts (“SMEs”) and stakeholders to CCB meetings as needed. During the transition from legacy system to the P3N, the legacy contractor may also be invited to attend.

4. Release Planning Meeting. Release Planning is the logical output of the CCB. Release Planning involves the scheduling of change orders (“CO”) agreed upon by the CCB and the impact to Department and P3N Business Operations. During the transition from legacy system to the Offeror’s system, release planning must account for changes to existing system components or functionalities. Release planning must also continue during the Maintenance and Operations phase of the P3N. Under the strategic guidance of the Department, the selected Offeror will facilitate the Release Planning Meetings, which include the Department, the legacy system contractor, and P3N system component contractors. The selected Offeror will produce a proposed system CO release schedule and documentation of its impact to P3N Business Operations. The Release Planning Meetings will convene on a frequency and at a time mutually acceptable to all stakeholders. Release Planning is comprised of Department resources from multiple program offices and the contractors who have the authority to make decisions related to the release. The Department resources may invite SMEs and stakeholders to the meetings as needed. During the transition from legacy system to the new P3N, the legacy system contractor may also be invited to attend.

5. Requirements Gathering related meetings. Under the strategic guidance of the Department, the selected Offeror will lead and document requirements-gathering and JAD sessions. The selected Offeror must participate in requirements-gathering-related meetings as directed by the Department.

6. Status Meetings. The selected Offeror must facilitate status meetings with the Department. Under the strategic guidance of the Department, the meeting will follow an agenda and allow the selected Offeror to report to the Department on the projects’ schedules, risks, issues, decisions, action items, and accomplishments, at a minimum.

The Offeror must describe its approach to facilitating and participating in meetings. The Offeror may propose additional meetings based on their experience with IT projects of this size and scope. DHS may require the Offeror to attend and facilitate other meetings at its discretion.

Offeror Response

E. Final Report. At the end of each contract year, the selected Offeror must submit a final

of 49

report, including: 1. The implementation status for any phased work 2. Number of organizations successfully onboarded and incorporated into the network 3. Training hours delivered per Phase 4. Summary of system utilization 5. Overall achievements 6. Challenges encountered 7. Recommendations for the following year

Offeror Response

I-10. Performance Standards. The Commonwealth has developed a set of minimum

Performance Standards, defined below, that the selected Offeror must meet or exceed in order to be in good standing. The Department may, at its discretion, assess liquidated damages. Where an assessment is defined as an “up to” amount, the dollar value will be set at the discretion of DHS.

The selected Offeror’s performance will be reviewed and assessed on a monthly basis. The DHS Contract Administrator (or designee) will give written notice of each failure to meet a performance standard to the selected Offeror. If DHS does not assess liquidated damages in an instance, DHS is not precluded from pursuing other or future assessments relating to those performance metrics and their associated damages. Describe your ability to meet or exceed these minimum performance standards.

Performance

Standard Minimum Acceptable Non-Compliant Remedial Action

Key Personnel Executive Account Director Project Manager Technical Manager Testing Manager Training Manager

Failure to notify DHS Contract Manager of voluntary diversion within thirty (30) calendar days may result in the Department assessing liquidated damages of up to $2,500. Failure to interim fill a Key Personnel vacancy within thirty (30) calendar days or permanently fill a vacancy within ninety (90) calendar days may result in a penalty of up to $2,000 per day for each day vacancy.

System Availability (Production)

Access to all production P3N Project activities are available for all P3N users at all times, except during scheduled maintenance.

Any unscheduled downtime, whether consecutive or intermittent, cannot exceed one (1) hour per calendar month in total. • Unscheduled downtime in excess of one (1)

hour but fewer than five (5) hours in one (1) month may result in the Department assessing up to $250 for each partial and full hour in liquidated damages.

• Unscheduled downtime exceeding five (5) hours per month but fewer than twelve (12) hours may result in the Department assessing up to $500 for each partial and full hour in liquidated damages.

• Unscheduled downtime exceeding twelve (12)

of 49

hours per month may result in the Department assessing up $1,000 for each partial and full hour in liquidated damages.

System Availability (non Production)

All training and testing environments will be available 6 a.m. to 6 p.m., Monday through Friday, and as agreed to during testing windows.

Any unscheduled downtime for each environment whether consecutive or intermittent cannot exceed five (5) hours per calendar month in total. • Unscheduled downtime in excess of one (1)

hour but fewer than eight (8) hours in one month may result in the Department assessing up to $500 in liquidated damages.

• Unscheduled downtime exceeding ten (10) hours per month may result in assessing up to $1,000 in liquidated damages.

Disaster Recovery

Plan and test annually and submit report to the Department for approval.

Failure to provide will result in a penalty of up to $1,000 annually.

Annual Security Assessment

The selected Offeror must perform an annual security assessment to evaluate the security measures being taken to protect the data hosted and maintained by the selected Offeror.

Failure to timely perform an annual security assessment may result in the HHSDC assessing liquidated damages of up to $10,000 annually.

Response Time Response time requirement threshold is less than or equal to five (5) seconds.

For each hourly average that exceeds the threshold response time in a calendar month, the Department may assess up to $2,500 in liquidated damages.

P3N – 7 Reporting

Standard, recurring reports must contain accurate data and be made available by the date and time specified by the Department. • Daily reports - due by 8 a.m. of the

next business day • Weekly reports - due by 12 p.m. of

the first business day of the following week

• Monthly reports - due by 8 a.m. the 5th business day of the following month

• Quarterly Reports due by 8 a.m. the 1st business day the third week of the first month following the end of the quarter

• Annual reports - due by 8 a.m. the 1st business day of the second month of the following year

• All other reports not defined above will be due as mutually agreed upon during JADs.

The Department will review report accuracy and delivery on a monthly basis. • Any report containing data the Department

determines to be incorrect may result in the Department assessing liquidated damages in the amount of up to $250 for each incorrect report.

• Each report delivered after the time specified and due date may result in the Department assessing liquidated damages in the amount of up to $250 for each late report.

Compliance Adhere to and remain current with applicable state and federal laws, rules, regulations, guidelines, policies, and procedures relating to information systems, information systems security and privacy, physical security, PHI confidentiality and privacy, the Americans with Disabilities Act, and Section 508 of the Rehabilitation Act.

The Department may assess liquidated damages of up to $2,500 plus any incurred cost for remediation for each non-compliance condition identified during the course of normal day to day operations, as the result of a finding in an audit, or as reported in a monthly report.

Security Incident Reporting

All system security incidents must be reported to the DHS Contract

Failure to report incident or provide sufficient response to any security breach may result in the

of 49

Administrator within fifteen (15) minutes of incident identification regardless of the known scope of the incident. Misuse of IT resources, loss or theft of equipment (USB drives, laptops, smartphones etc.) that may contain Department data must be reported via email to the DHS Contract Administrator or designee within one (1) hour of the incident. All incidents will be required to follow incident handling procedures to include scope of incident, containment, eradication, and recovery, as appropriate to the situation.

Department assessing liquidated damages in the amount of up to $10,000 per security breach not reported.

A. For any deficiency, including ones relating to the performance metrics, the selected

Offeror will prepare and submit a Corrective Action Plan (“CAP”) for any observation or finding contained in a notice of deficiency. Unless another time period has been specified for submission, the selected Offeror must submit the CAP to the Department within ten (10) business days of notification of the deficiency or such longer time as may be agreed to by the Department.

B. The selected Offeror must include in the CAP: 1. Brief description of the findings; 2. Specific steps the selected Offeror will take to correct the situation or reasons why it

believes corrective action is not necessary; 3. Name(s) and title(s) of responsible staff person(s); 4. Timetable for performance of the corrective action steps; 5. Monitoring that will be performed to ensure that corrective action steps were

implemented; and 6. Signature of the selected Offeror’s Executive Director

C. The selected Offeror must implement the CAP within the timeframe agreed to by the

parties for that particular CAP. Failure to implement a CAP, in the manner agreed to, may result in further action by the Department, including, but not limited to, a finding of default.

D. In the event the Department determines a deficiency to be a serious non-compliance with the selected Offeror’s obligations under the contract, the Department may find the selected Offeror in default.

The Offeror should provide its approach to meeting the Performance Standards. . Offeror Response

I-11. Conflicts. Current certified P3N Participants are precluded from being selected for negotiations or contract award for this RFP. Current P3N certified Participants are also precluded from being a subcontractor for the selected Offeror of this RFP. Offeror Response

of 49

I-12. Objections and Additions to Standard Contract Terms and Conditions. The Offeror will identify which, if any, of the terms and conditions contained in the Standard Contract Terms and Conditions Attachment it would like to negotiate and what additional terms and conditions the Offeror would like to add to the standard contract terms and conditions as part of its Technical Submittal, not via the Question and Answer process. The Offeror’s failure to make a submission under this paragraph will result in waiving its right to do so later, but DHS may consider late objections and requests for additions if to do so, in DHS’s sole discretion, would be in the best interest of the Commonwealth. DHS may, in its sole discretion, accept or reject any requested changes to the standard contract terms and conditions. The Offeror shall not request changes to the other provisions of the RFP, nor shall the Offeror request to completely substitute its own terms and conditions for the Standard Contract Terms and Conditions Attachment. All terms and conditions must appear in one integrated contract. DHS will not accept references to the Offeror’s, or any other, online guides or online terms and conditions contained in any proposal. Regardless of any objections set out in its proposal, the Offeror must submit its proposal, including the cost proposal, on the basis of the terms and conditions set out in the Standard Contract Terms and Conditions Attachment. DHS will reject any proposal that is conditioned on the negotiation of the terms and conditions set out in the Standard Contract Terms and Conditions Attachment, or to other provisions of the RFP as specifically identified above. Offeror Response

TECHNICAL SUBMITTAL the final resolution of the cancellation or the termination. The Offeror must...

Documents

Transcript of TECHNICAL SUBMITTAL the final resolution of the cancellation or the termination. The Offeror must...