B08_SOL_-_Attachment_2_-_Peformance_Work_Statement_Template.pdf

Indian Health Service

HEALTH INFORMATION TECHNOLOGY

MODERNIZATION PROGRAM

Performance Work Statement Template

Engineering and Architecture Modeling Software Acquisition

Performance Work Statement Health Information Technology Modernization Program

Acquisition Sensitive

PURPOSE

The purpose of this Performance Work Statement (PWS) template is to assist Quoters in structuring their quotes in response to the Indian Health Service (IHS) Enterprise and Architecture Modeling Software (EAMS) Statement of Objectives (SOO). This template is intended to facilitate quoters’ submission of a complete and executable quote that thoroughly addresses the EAMS objectives and documents the tasks and associated deliverables necessary to execute their proposed solutions.

PERFORMANCE DETAILS

Period of Performance The period of performance (PoP) will comprise a one (1)-year base period with four (4) one (1)-year option periods. The full PoP is five (5) years. The base year will begin on contract award and will end 12 months thereafter.

TECHNICAL PROPOSAL / PERFORMANCE WORK STATEMENT

The Quoter shall provide a detailed description of the proposed Enterprise Architecture (EA) development environment and include a discussion of how their solution meets the topics outlined below.

Enable development of the IHS EA through which IHS developers will model IHS business processes, services, enterprise software capabilities, and information technology infrastructure.

Provide decision support models and other digital products to IHS leadership to inform IHS’s development decisions and analyze the impact of those decisions across cost, schedule, performance, and systems perspectives.

Provide a means to standardize terms, processes, and data across IHS and with IHS stakeholders.

Implement data storage and management consistent with the Federal Risk and Authorization Management Program (FedRAMP), Personally Identifiable Information (PII)/Personal Health Information (PHI), and other security requirements.

Support collaborative development and review of models and other digital products natively and through export to dashboards and other tools.

Provide IHS leaders with the information needed to visualize current, interim, and objective states of the IHS system; visualize gaps; and do so natively and through export to dashboards and other tools.

TASKS AND DELIVERABLES

Quoters shall describe in their quotes how the EAMS tool they provide will meet each of the following Tasks and Deliverables, providing sufficient scope and detail to ensure confidence that all of the described elements will be fully addressed. The Quoter must address all of Threshold (T) capabilities in the submitted PWS. The Quoter should only address the Objective (O) capabilities that they are able to provide with their solution in the submitted

PWS.

Task 1: Software Functional Capabilities The software shall meet the functional requirements listed in Table 1 below, which represent the functional requirements for this solicitation. Those labeled Threshold (T) represent the minimal capabilities the vendor must meet to be considered viable for this acquisition. Those labeled Objective (O) represent the Government’s desired capabilities for a solution that would meet all current and anticipated future needs.

Table 1: Task 1 – Functional

ID Title Description

F-1 Development Framework

The software shall provide a vendor-specific development process for Enterprise Architecture using a specified framework, e.g., Unified Architecture Framework (UAF), and a system modeling language (SysML) that may be used as an option by IHS developers. The software will not preclude or hamper IHS developers’ ability to use their own development process in addition to the vendor-specific process. (T)

ID Title Description

F-2 Architecture Framework: Unified Architecture Framework (UAF)

The software shall support development using the Unified Architecture Framework (UAF). (O)

F-3 Architecture Framework: DoD Architecture Framework (DoDAF)

The software shall support development using the DoD Architecture Framework (DoDAF). (O)

F-4 Architecture Framework: The Open Group Architecture Framework (TOGAF)

The software shall support development using The Open Group Architecture Framework (TOGAF). (O)

F-5 Architecture Framework: Federal Enterprise Architecture Framework (FEAF)

The software shall support development using the Federal Enterprise Architecture Framework (FEAF).

(O)

F-6 Architecture Framework: Eclipse Modeling Framework

(EMF)

The software shall support development using the Eclipse Modeling Framework (EMF). (O)

ID Title Description

F-7 Modeling Language:

Unified Modeling Language (UML)

The software shall support development using the Unified Modeling Language (UML). (O)

F-8 Modeling Language:

Systems Modeling Language (SysML)

The software shall support development using the Systems Modeling Language (SysML). (O)

F-9 Modeling Language:

Business Process Modeling Notation

(BPMN)

The software shall support development using the Business Process Modeling Notation (BPMN). (T)

F-10 Modeling Language:

Case Management Modeling Notation

(CMMN)

The software shall support development using the Case Management Modeling Notation (CMMN). (O)

F-11 Modeling Language:

Decision Modeling Notation (DMN)

The software shall support development using the Decision Modeling Notation (DMN). (O)

F-12 Architecture Framework:

Extensions

The software shall enable custom extensions to architecture frameworks to support IHS development processes. (T)

F-13 Modeling Language:

Extensions

The software shall enable custom extensions to modeling languages to support IHS development processes. (T)

ID Title Description

F-14 Ontology: National Emergency Medical Services Information System (NEMSIS)

The software shall support development using data definitions and metadata from the National Emergency Medical Services Information System (NEMSIS) standard. (O)

F-15 Ontology: National Information Exchange Model

(NIEM)

The software shall support development using data definitions and metadata from the National Information Exchange Model (NIEM) standard. (O)

F-16 Ontology: Health Level 7 International (HL7) Fast Healthcare Interoperability Resources (FHIR)

The software shall support development using data definitions and metadata from the Health Level 7 International (HL7) Fast Healthcare Interoperability Resources (FHIR) standard. (O)

F-17 Collaborative Development

The development environment shall support ten (10) developers working on the same model in a shared environment. (T)

F-18 Review Support The development environment shall provide the means for reviewers who are not experts in EA development to review models and other data and provide comments, and for these comments to be traced and actionable by developers. (T)

ID Title Description

F-19 Modeling Language:

Entity Relationship

(ER)

The software shall support development using the ER modeling notation. (O)

F-20 Modeling Language:

Other Diagram Types

The software shall support the creation of fishbone diagrams; responsible, accountable, consulted, and informed (RACI) diagrams; and Mind Map diagrams.

(O)

F-21 Domain Modeling:

Requirements Management

The software shall support requirements development and management. (T)

1.1 Task 2: Security Capabilities

The software shall meet the security requirements outlined in Table 2 below, which represent the security requirements for this solicitation. Those labeled Threshold (T) represent the minimal capabilities the vendor must meet to be considered viable for this acquisition. Those labeled Objective (O) represent the Government’s desired capabilities for a solution that would meet all current and anticipated future needs.

Table 2: Task 2 – Security

ID Title Description

S-1 Data Protection – IHS Sensitive

The development environment shall provide protection of IHS sensitive data in accordance with Part 10 of the Indian Health Manual. (https://www.ihs.gov/ihm/pc/part- 10/) (T)

ID Title Description

S-2 Data Protection –

PII/PHI

The development environment shall provide protection of PII/PHI data in accordance with Part 10 of the Indian Health Manual, Privacy Act, Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy Rules, and HIPAA Security Rules. (T)

S-3 Role-based Access For server-side data and model management tasks, the administrator will be able to restrict access to models/data based on the user’s role. (T)

S-4 User Access Control The minimum user identity and access control method permissible is individual username and password that can be assigned to authorization groups. (T)

S-4a User Access Control If the development environment is installed on-premises (on-prem) (i.e., on customer’s physical, virtual, or cloud-based servers), then the software shall integrate with Lightweight Directory Access Protocol (LDAP) for user authentication and authorization. (O)

S-4b User Access Control If the development environment is cloud-based SaaS, the software shall implement a two-factor authentication mechanism. (O)

ID Title Description

S-5 Authority to Operate The vendor shall provide all documentation (e.g., data, test results, proof of control compliance) needed to support an Authority to Operate (ATO) decision, and if configuration changes are needed to achieve ATO, the vendor shall make such changes and provide evidence of those changes. (T)

S-6 FedRAMP Any development environment that is cloud-based Software as a Service (SaaS) shall be FedRAMP- Moderate certified. (T)

S-7 Limited Environment Reach-back

If the development environment is installed on-prem (on customer’s physical, virtual, or cloud-based servers) and requires an external network connection, a description of all such communications methods and content shall be provided. (T)

1.2 Task 3: Technical Capabilities

The software shall meet the following technical requirements, which represent the technical requirements for this solicitation. Those labeled Threshold (T) represent the minimal capabilities the vendor must meet to be considered viable for this acquisition. Those labeled Objective (O) represent the Government’s desired capabilities for a solution that would meet all current and anticipated future needs.

Table 3: Task 3 – Technical

ID Title Description

T-1 Browser-based Development Environment

The development environment shall be accessible through a web browser on a user's computer. (O)

T-2 Client-based Development Environment

The development environment shall offer a client application that can be installed on a user's computer in both Windows (T) and Macintosh Operating System (MacOS) (O) environments.

T-2b Server-based Development Environment

The development environment shall include an on-premises (on-prem) installation option (i.e., on customer’s physical, virtual, or cloud-based servers).

(O)

The development environment shall include a cloud-based SaaS option. (O)

T-3 Data Management Software shall support server-side models, and data management provide a central repository accessible by client and virtual development environments. (T)

T-4 License Management License shall be locally managed, with all licenses available to users on the local network. (T)

ID Title Description

T-5 License Types For both client/server and virtual/cloud applications, the software shall allow the use of floating licenses.

(T)

For both client/server and virtual/cloud applications, the software shall have an option to allow administrators to reserve some floating licenses for specific users. (O)

T-6 Virtualization-based Development Environment

The development environment shall be installable and accessible to users through a Virtual Machine (VM) or similar virtualization environment. (T)

T-7 API Access The software shall support the import, export, and discovery of data using Open Services for Lifecycle Collaboration (OLSC) and the Representational State Transfer (REST) application program interface (API).

(T)

T-8 Scalability The software shall provide support for working with very large data sets (greater than 10,000 unique data elements) with multiple linkages between data elements. (T)

T-9 Concurrent Users The development environment shall provide the capability for 10 (T) users to concurrently execute development work.

ID Title Description

T-10 Offline Development The development environment shall support disconnected users and enable the synchronization of offline content with server-side data. (O)

T-11 Interoperability: Data Import

The software will have the capability to import the following:

Comma Separated Value (CSV)/Excel, Extensible Markup Language (XML) UML 2.1/2.5 XML Metadata Interchange (XMI), Meta Object Facility (MOF) XMI, Model Systems of Systems Architecture (MSoSA), Quality-related information (RDQIF), Eclipse UML2 XML, XPDL/BPMN2, KPMN. (O)

T-12 Interoperability: Data Export

The software will have the capability to export the following:

CSV/Excel, UML 2.5 XMI, MOF XMI, MSoSA XML, RdqIF, Eclipse UML2 XML, XML for Process Definition Language (XPDL)/BPMN2, HyperText Markup Language (HTML), BPMN. (O)

T-13 Interoperability:

Architecture Tool-specific Data Exchange

The software shall be able to import/export model files from/to the following tools using native import/export routines (O): Sparks Enterprise Architect, Dassault Systemes MSoSA, Unicom System Architect, International Business Machines (IBM) Rhapsody.

T-14 Interoperability: Analysis Tool-specific Data Exchange

The software shall be able to import/export model files from/to the following tools using native import/export routines (O): Matlab/Simulink, Modelica.

ID Title Description

T-15 Interoperability: Database-specific Data Exchange

The software shall be able to import/export model data from/to database sources using (O): MOF Model to Text Transformation Language (MOFM2T), OLSC, REST API, JavaScript Object Notation (JSON), XML, and SysML.

T-16 Configuration Management: Individual Elements

The software shall support configuration management of data elements, e.g., a specific requirement object, and of information/models built from these data elements, e.g., a SysML Requirements Diagram.

Elements placed under configuration management can be restricted from being changed. (T)

T-17 Configuration Management: Baselines

The software shall support the development and configuration of model baselines. Each baseline will include model views and related data as specified by the developer. Elements placed within a baseline can be restricted from being changed. (T)

T-18 Configuration Management: Model Versioning

The software shall support versioning at the EA model level, encompassing all baselines and other configuration-managed data contained within that model. The software shall capture version author(s) and change notes. This capability will allow model-level excursions or branches that can be merged at the discretion of the developers. (T)

ID Title Description

T-19 Reporting: Common Office Formats

The software shall support the export of selected model views and underlying data into common office automation formats (e.g., Microsoft Word, Microsoft Excel, Google Docs, and Google Slides) using built-in templates and scripts. IHS developers shall be able to modify these templates and scripts as required. (T)

T-20 Reporting: Dashboards and Websites

The software shall support the export of selected model views and underlying data into common dashboards (e.g., Qlik, Tableau, Power BI) and hosted web locations (e.g., WordPress site, SharePoint site), using built-in templates and scripts. IHS developers shall be able to modify these templates and scripts as required. (T)

T-21 Query-Report The software shall provide a means to write queries and print reports based on returned elements. (T)

T-22 Search The software shall provide the ability to search for modeling elements across models and indicate to the user where search elements were found. (T)

1.3 Task 4: Training Capabilities

The software and/or vendor services shall meet the training requirements outlined in Table 4 below, which represent the training requirements for this solicitation. Those labeled Threshold (T) represent the minimal capabilities the vendor must meet to be considered viable for this acquisition. Those labeled Objective (O) represent the Government’s desired capabilities for a solution that would meet all current and anticipated future needs.

Table 4: Task 4 – Training

ID Title Description

TR-1 Information Technology (IT) Training: In person or instructor led virtual

The vendor will offer in person or instructor led virtual (to be mutually agreed to by the government and contractor) training for the installation, configuration, integration, and sustainment of its development environment in client, server, and virtual environments.

(T)

TR-2 IT Training: On-demand The vendor will offer on-demand training for the installation, configuration, integration, and sustainment of its development environment in client, server, and virtual environments. (T)

TR-3 User Training: In person or instructor led virtual

The vendor will offer in person or instructor led virtual (to be mutually agreed to by the government and contractor) training for development staff covering how to use the tool for individual and collaborative development, as well as the development methods the software supports. (T)

TR-4 User Training: On-demand

The vendor will offer on-demand training for development staff covering how to use the tool for individual and collaborative development, as well as the development methods the software supports. (T)

ID Title Description

TR-5 Admin Training: In person or instructor led virtual

The vendor will offer in person or instructor led virtual (to be mutually agreed to by the government and contractor) training for administrative staff covering how to set up modeling environments, manage model data, provide user and role management, and configure collaborative and web-based views. (T)

TR-6 Admin Training: On-demand

The vendor will offer on-demand training for administrative staff covering how to set up modeling environments, manage model data, provide user and role management, and configure collaborative and web-based views. (T)

TR-7 Online Help The software will offer online help that supports IT, User, and Admin roles to execute development. This online help will be accessible internally to the IHS network (T) and externally (O).

TR-8 Vendor-neutral Modeling Training

The vendor shall provide in person or instructor led virtual (to be mutually agreed to by the government and contractor) or on-demand training for development staff covering how to develop and maintain enterprise architectures independent of any specific modeling software. (T)

1.4 Program Use Cases

The software shall support the following use cases. The Quoter shall describe in their quotes how the EAMS tool they provide will support all of the following Use Cases, providing sufficient scope and detail to ensure confidence that all of the described elements will be fully addressed.

Table 5: Use Cases

ID Title Scenario Objective

UC-1 Collaborative Development

Five geographically distributed developers are working on the same part of the EA concurrently and must be able to work on their portions without impacting the work of other developers.

Demonstrate that multiple, geographically dispersed developers can work concurrently on the same model.

UC-2 Leadership Decision Making

IHS leadership is being briefed on a change to how the case management system will be configured. The leaders want to understand the impact on training, program cost, overall schedule-based recommended software, and business process changes.

Demonstrate that developers can present a sample patient case management business process traced to the underlying IT services and system, inclusive of cost and schedule perspectives.

Demonstrate that developers can present this information to leaders in a format that allows them to make informed decisions.

ID Title Scenario Objective

UC-3 Model Review IHS has engaged a group of external subject matter experts to review a set of business processes and the IT services that support them. The review is led by a facilitator describing the products to the experts. Real-time feedback is captured by the facilitator in the model. Later, the experts provide their written feedback directly into the model from their home location.

Demonstrate that a facilitator can generate views for use during a working session with experts, which can be used to capture real-time feedback. Demonstrate that an expert can provide written and graphical feedback on models and explain data elements from a remote location without having to be an expert in the EA tool itself.

UC-4 Configuration Management

An IHS administrator is building a deployment baseline consisting of business processes, services, and infrastructure model views with underlying data. This baseline needs to be traced to the previous baseline to illustrate changes.

Demonstrate that the software supports building a baseline that contains many different views and data and the capability to trace this baseline to a previous baseline.

ID Title Scenario Objective

UC-5 Tool Interoperability

An IHS developer has been given a model developed in another EA tool. The developer needs to import this model into the selected EA tool.

Demonstrate the software’s ability to import a model developed in the UAF framework, using both BPMN and SysML languages, from a different tool into the vendor’s tool. Describe limitations.

UC-6 Data Interoperability

An IHS developer is linking requirements data captured in the vendor's tool to the same requirements data captured in a Structured Query Language (SQL) database on a SharePoint site. The developer needs the capability to link like data and get an indication when the data on either side of the link has changed.

Demonstrate the software’s ability to link model data from the vendor's tool to the matching data in an external data source. Describe limitations.

ID Title Scenario Objective

UC-7 Services Development

An IHS developer is building services views as part of the IHS EA. The developer needs to trace these services to the business process they enable and the underlying IT infrastructure upon which they reside.

Demonstrate the software's ability to develop services views in accordance with (IAW) a chosen architecture framework and trace the services to an example business process developed in BPMN and to an example IT system developed in SysML.

UC-8 Business Process Development

An IHS developer is building business process views as part of the IHS EA. The developer needs to trace these business processes to source requirements, use cases, and the services, messages, and other system elements that enable the process.

Demonstrate the software's ability to develop business process views IAW a chosen architecture framework in the BPMN language. Trace these processes to source requirements and use cases, as well as supporting service and infrastructure.

ID Title Scenario Objective

UC-9 Reporting An IHS branch chief, who does not normally use the EA tool, needs to generate a report for specific use cases matched to the business process views that implement the use case. The report will provide a snapshot of current work.

Demonstrate that a non-technical user can generate a report using IHS letterhead, graphics, headers, and footers, illustrating a sample use case and business process views traced to that use case.

UC-10 Model Storage and Curation

The model is stored in an environment (locally or cloud hosted) where models can be collectively accessed by multiple team members.

Models can be segmented in a number of ways, for example, by type of user, type of view, or by intended use, and selectively published so only a subset of authorized users can access this portion of the model.

Team members can check out parts of a model simultaneous as other modelers check out other sections of the model.

List of Deliverables The deliverables outlined in Table 6 below will be required after award. The Quoter shall include these deliverables in their PWS.

Table 6: Deliverables

Number Title Task Section Description Frequency Format 1 Software End User

Access 0, 1.1, 1.2 Contractor shall provide software accessibility to end users.

As required Contractor Format Acceptable

2 Training Plan 1.3 The contractor shall submit a training plan outlining the method of training delivery, frequency of training, training schedule, and an overview of training content.

60 days after contract award and monthly if changes to the Plan are required by IHS or if changes are recommended by the Contractor

Contractor Format Acceptable

3 Training Participant Feedback Survey

Error!

Reference source not found.

The contractor shall develop a training survey to capture the overall training satisfaction of participants.

60 days after contract award and within 30 days after the completion of training is conducted

Contractor Format Acceptable

GENERAL REQUIREMENTS

Section 508 – Information and Communication Technology (ICT) Standards The contractor shall deliver a solution and products in compliance with Section 508 of the Rehabilitation Act of 1973, as amended in 1998 (29 U.S.C. 794(d)) and in accordance with Health and Human Services Acquisition Regulation (HHSAR) Part 339.205.