ATTACHMENT 1 PWS CDS IDIQ_FINAL.docx

PERFORMANCE WORK STATEMENT (PWS)

DEPARTMENT OF VETERANS AFFAIRS

Office of Informatics and Information Governance (OIIG) Knowledge Based Systems (KBS)

Project Title: Clinical Decision Support (CDS) Services IDIQ Project Number: TBD Date: 07/22/2020 PWS Version Number: 2.26

Table of Contents

BACKGROUND

CIDMO, KBS and CDS Overview The Veterans Health Administration (VHA), Office of Health Informatics (OHI), Clinical Informatics and Data Management Office (CIDMO), Office of Knowledge Based Systems (KBS) provides subject matter expertise, policy guidance, and strategic recommendations regarding clinical decision support (CDS) standards implementation for the Department of Veterans Affairs (VA) Information Technology (IT) systems.

The mission of CIDMO is to improve lives of Veterans and staff through better data and tools for better decisions and workflows. CIDMO seeks to help VHA realize its goal to become an agile learning organization through user-centered standardization of health information, clinical processes, and technologies by building standardized best informatics practices for improved field informatics capacity along with robust clinical process modules with Health Information Technology (HIT) configurations.

The mission of KBS is to improve the ability of clinicians to provide care for patients while increasing quality, safety, and efficiency. As part of this mission, KBS seeks to implement CDS within electronic health records (EHRs) broadly, and within VA health information systems specifically (the current, “legacy” VA EHR is the Computerized Patient Record System (CPRS)). CDS provides clinicians, staff, patients or other individuals with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and health care.[footnoteRef:2] It encompasses a variety of tools and interventions, such as computerized alerts and reminders, clinical guidelines, order sets, patient data reports and dashboards, documentation templates, diagnostic support, and clinical workflow tools. [2: Clinical Decision Support (CDS), “What is Clinical Decision Support (CDS)?” HealthIT.gov website, https://www.healthit.gov/policy-researchers-implementers/clinical-decision-support-cds (Accessed 2020-07-18).]

Knowledge Based Systems Office, KBS, is organized into four separate components, as discussed below. While the Contractor will primarily support the CDS component, the Government anticipates that the Contractor will need to interact with Federal and/or Contractor staff from any or all of the other KBS components shown below.

· Clinical Decision Support: Provides subject matter expertise on CDS to internal and external collaborators, and supports modeling and implementation of VHA’s current and future CDS strategy by identifying and exploring CDS capabilities needed to optimally support patient care.

· Terminology: Provides expert clinical terminology consultation, terminology creation, matching, and modeling to support semantic interoperability and reasoning capabilities in health records.

· Informatics Architecture: Defines VA strategy and architecture as it relates to representation of patient-specific clinical data and knowledge within VA health information systems and with the technical methodologies used to process data for patient care, quality assurance, and secondary uses. The Contractor shall not be responsible for creating VA’s overall strategy and architecture for informatics.

· Standards and Interoperability: Provides expert health standards analysis, creation, engagement and consultation, contributing to a common framework for functional and semantic interoperability by sharing VA requirements and supporting solutions to achieve intelligent health information exchange that extends to enhanced patient care. The Contractor shall not be responsible for creating VA’s overall strategy with respect to Standards and Interoperability.

CDS Content Clinical content is considered an essential, indepensible element of CDS. Although most attention in the Informatics literature is given to the algorithms, formalisms, standards, and user interfaces delivering CDS, identifying and creating expert clinical content arguably requires the majority of the intellectual work and may be the single most important contributor to the success or failure of most CDS interventions. For example, CDS content can be effective when delivered via traditional paper charts, such as early versions of the Regenstrief Medical Record System.

Healthcare providers have little tolerance for poorly thought out CDS. Provider intolerance can and will rapidly generalize if CDS systems deliver interventions that are perceived as clinically incompetent. Creators of clinical content have to “get it right” if provider adoption is expected.

The answer to the question “what is CDS clinical content” is complex. At its highest level, CDS clinical content is expert knowledge that is both patient-aware and clinically savvy. CDS content must be understandable, useful, evidence-based, properly targeted, clinically correct, and organizationally acceptable. Clinical content must also be maintained over time. The practice of medicine changes as new knowledge and products emerge through research and development. As with all clinical interventions, the content for CDS must be reviewed and updated to reflect current clinical practice or risk becoming incompetent.

Clinical Decision Support Knowledge Artifacts Through this effort, the government seeks to obtain and/or update various Clinical Decision Support Knowledge Artifacts (“CDS artifacts”) to improve and enhance the care of Veterans. CDS artifacts are individual objects that represent unique items of clinical knowledge and/or best practices in the provision of clinical care that can be used, either individually or in conjunction with other items, to provide clinical staff with effective clinical decision support. The creation of CDS artifacts may rely on any of the following:

Arden Syntax

Image Processing/ Classificaton

Predictive models

Shareable CDS Knowledge Artifacts VHA has developed and fine-tuned a substantial amount of CDS Artifacts within its EHR in the form of clinical reminders, order sets, note templates, etc. However, as in many other healthcare organizations, the CDS currently implemented is in a non-standard, non-shareable format tightly dependent on specific legacy technology. Consequently, healthcare organizations are spending valuable resources to create the same or similar CDS that is used exclusively within their respective EHRs. One emerging approach to enable the widespread sharing of CDS content is through representation of computable CDS content in a standard, system-agnostic format. Libraries of CDS content represented in a standard format could be made available in central knowledge repositories. CDS engines and clinical information systems would be able to download and import CDS content from these repositories for execution within a specific environment.

In support of this effort, several standard knowledge representation formalisms have been developed in the past, with variable degrees of adoption, including Arden Syntax, Health Level 7 (HL7) GELLO, and the HL7 CDS Knowledge Artifact Specification (KAS)[footnoteRef:3]. The HL7 KAS, initially released as a Draft Standard for Trial Use in 2015, aligned at that time with the Health eDecisions[footnoteRef:4] (HeD) Initiative’s Artifact Sharing Use Case (HeD Use Case 1) sponsored by the Office of the National Coordinator for Health IT (ONC). As further described in Addendum C below, the HL7 KAS provides a standard CDS format that enables healthcare organizations such as VA to share and/or use the CDS knowledge/content of CDS knowledge artifacts. Going forward, VA intends to align with current and future efforts for CDS knowledge artifact creation, representation, and utility using standards such as FHIR, Clinical Quality Language (CQL)[footnoteRef:5], and Analysis Normal Form (ANF)[footnoteRef:6]. [3: Health Level 7 (HL7) Standard: “Clinical Decision Support Knowledge Artifact Specification, Release 1.3, Draft Standard for Trial Use (DSTU), July 2015, http://www.hl7.org/implement/standards/product_brief.cfm?product_id=337] [4: https://wiki.hl7.org/index.php?title=Health_eDecisions ] [5: https://ecqi.healthit.gov/cql] [6: https://confluence.hl7.org/display/CIMI/Analysis+Normal+Form+%28ANF%29+Project ]

For recent CDS artifact creation, VA used the HL7 KAS. As the HL7 KAS is modified and/or replaced, the contractor shall be required at the Government’s direction to adopt and use the standard(s) that augment or replace the HL7 KAS. In the event that a new standard is released while the Contractor is engaged in the process of creating certain knowledge artifacts, the Government will not require the Contractor to revise deliverables that have proceeded past a certain point in a task order under way, as defined in the task order.

For the purposes of this effort, we will use interchangeably the terms “CDS knowledge artifacts”, “CDS artifacts” or simply “knowledge artifacts” to refer to clinical decision support knowledge artifacts whether or not they are compliant with the HL7 KAS or other standard. However, regardless of the term used, the Contractor shall be required to deliver CDS knowledge artifacts compliant with whatever standard the Government specifies at the individual Task Order level. Hisotrically, we have used the term “KNART” to refer specifically to CDS knowledge artifacts compliant with the HL7 KAS. In the event that the proper name is deprecated by HL7, the use of “KNART” in this PWS or during this effort will refer to knowledge artifacts in whatever way they are renamed. This may also include other types of knowledge artifacts (e.g., FHIR Clinical Reasoning Module).

The VHA aims to share CDS for use in VA facilities across the US, and outside the VA. The VHA currently is modernizing its electronic health record system, an effort called Electronic Health Record Modernization (EHRM) which includes intent to implement a commercial off the shelf EHR (Cerner). The artifacts created pursuant to this effort will support this goal and also enable the VHA to leverage externally published CDS content including but not limited to clinical knowledge, clinical algorithms, clinical data, and clinical contextual information, in a specific format. Clinical content can be structured as a CDS Artifact for use in a CDS intervention via the EHR. An example of a CDS Artifact would be an application incorporating a clinical practice guideline for recommending pneumococcal vaccination for patients with chronic diseases or over age 65 unless they are allergic to components of the vaccine or have been vaccinated within the past ten years.

KBS previously engaged in a 15-month contracted effort which took initial steps toward widespread sharing of CDS by creating the content for ECA rule, order set, documentation template, consult request, composite, and E-Consult request knowledge artifacts, followed by conceptualizing and creating the appropriate extensible markup language (XML)-based representations of such knowledge artifacts in compliance with the HL7 CDS KAS. That prior effort resulted in vetted clinical content for and XML renderings of approximately 100 CDS knowledge artifacts.

Under this new IDIQ, the contractor is intended to leverage our prior KBS efforts to inform the creation of additional content for newly conceptualizing and creating system agnostic representations of ECA rule, order set, documentation template, and composite CDS knowledge artifacts. The performing Contractor may also be required to update/enhance/extend existing CDS artifacts to help ensure their compliance with new or updated standards or requirements identified by the Government at the time of an individual Task Order.

VA anticipates that the CDS artifacts created during the course of performance for this effort may be made available in central knowledge repositories, including publicly available repositories such as CDS Connect[footnoteRef:7]. Further, VA also anticipates there will be future use of CDS engines and clinical information systems to search and download CDS knowledge artifacts (such as those created during performance of this effort) for implementation and execution within the VA EHR environment after the performance and completion of this effort. [7: https://cds.ahrq.gov/

Terminology The CDS knowledge artifacts for this effort rely on terminology standards, including Systematized Nomenclature of Medicine (SNOMED) Clinical Terms (CT), Logical Observation Identifier Names and Codes (LOINC), and RxNorm, to support semantic interoperability. For example, a CDS rule that reminds clinicians to measure peak and trough blood levels of the antibiotic gentamicin (prior to administering the next gentamicin dose to a patient), must be triggered by medication orders for gentamicin (coded in RxNorm), must allow clinicians to easily generate lab orders (coded in LOINC), and must prevent inappropriate medication orders for gentamicin in patients with renal insufficiency (coded in SNOMED) on the patient problem list.

The KBS Informatics Architecture's “Solor” effort[footnoteRef:8] works to advance patient safety, Health IT operability, and Health IT interoperability through the specification, simplification (through integration of overlapping standards), and deployment of a common knowledge architecture across VA systems. While many medical terminology giants create and manage medical terminologies, Solor integrates key terminologies into one, standardized model. Through coordination of SNOMED, LOINC, RxNorm, and other terminologies as needed, Solor removes ambiguity from overlapping content and presents patient data in uniformity - allowing for consistent reasoning, and consistent interaction, regardless of its source terminology. This can result in improved operability and interoperability of HIT systems within the VA as well as with the private sector, to enable better care coordination, and more timely and higher-quality care for the Veteran. [8: https://solor.io/

The Analysis Normal Form (ANF)[footnoteRef:9] is a standardized, encoded, and machine-processable representation of clinical statement that is intended to safely and reliably support data analysis that can be used to aggregate data created using any standard or non-standard input form or exchange mechanism. ANF seeks to address the variability of how clinical data within value sets and Clinical Decision Support (CDS) rules are modeled and stored in data repositories. The goal of ANF is to enable analysts to understand the data and how it is stored, in lieu of having to teach them about the thousands of ways data can be entered (i.e., Clinical Input Form (CIF))[footnoteRef:10], and ensure the data we need expressed can be expressed in an operable and scalable way. The more that data is normalized, the simpler it will become to analyze, and the likelihood of analysis errors will be reduced. Without the ANF, the probability of patient safety risks is increased. Additional information about terminology content, Solor and ANF is included in Section 5.1.4. [9: http://solor.io/anf/ ] [10: Clinicians author clinical statements and enter them into their organization’s electronic health record typically via a manner that we call the clinical input form (CIF). However, the CIF is not a literal form that clinicians select and enter data in. Rather, it refers to the manner in which information is presented to the clinicians and how they enter the data, such as by constraining the information to allow only certain values to be entered, such as through a drop-down list or radio button, or breaking up large chunks of related information into smaller parts. For example, when a clinician orders a medication, rather than selecting this information all at once with a single item, they will choose the various parts of the medication order such as the name of the drug and strength, dose of drug and dosing frequency, route and duration of medication administration, and any constraints such as maximum daily dosage, etc. From http://solor.io/wp-content/uploads/2019/02/symbolic-information-analytics-20190226.pdf, p158. (accessed 2020-07-18)]

CDS Consultation A number of work efforts within KBS office serve as background information important to the context for this PWS, as they address broad issues related to CDS and may or may not relate directly to knowledge artifacts.

KBS in general is tasked with providing CDS standards and content support to VHA, VA, and Federal partners across a broad range of programs and projects. These efforts have ranged from collaborative ongoing maintenance of existing CDS in VistA/CPRS[footnoteRef:11] (e.g., sharing best of breed examples of CDS); individual projects (e.g., CDS Roadmap, “SMART” structured data capture documentation templates, etc.); major program initiatives (e.g., the modernization of the VA EHR); and Congressionally-mandated initiatives (e.g., VA DoD (Department of Defens) sharing and Community healthcare access). [11: Veterans Health Information System and Technology Architecture / Computerized Patient Record System (VistA/CPRS). https://en.wikipedia.org/wiki/VistA]

The KBS CDS Program Office receives frequent requests from VA stakeholders for support, guidance, and expertise on various projects. Some examples of recent consultations include Women’s Health, evaluating impact of CDS on VA clinical operations, and preparing for CDS with respect to the impending implementation of a commercial EHR (Cerner). Due to resource constraints and/or the specialized nature of these requests, KBS leverages its capability to asynchronously access critical CDS subject matter experts (SMEs) to address these ad-hoc requests in a timely manner that otherwise would be unmet or addressed with less than optimal solutions. The capability for the VA to access nation-leading informatics expertise will help ensure the success of our future HIT endeavors, including but not limited to work on: clinical data standards, CDS, interoperability, clinical workflow integration, human factors engineering, HIT impact assessment, and specialty specific informatics such as nursing, dental, public health, and pharmacy.

SCOPE OF WORK

This PWS provides both specific requirements (i.e., predefined) and functional categories which are considered to be more general in nature and are subject to further/subsequent refinement during the course of contract performance. Specific requirements are described in Section 5.0. Functional categories subject to additional definition are described in Section 6.0. It is anticipated that further definition and/or refinement of these performance requirements will be addressed at the individual task order level and shall be further defined within individual task orders. Generally, requirements shall be in accordance with Sections 5.0 and 6.0 of this PWS. It is possible, however, that additional requirements under this effort may arise which call for support efforts consistent with the CDS lifecycle stages published in 2011 by Wright, et al (Attachment A). Furthermore, as the general requirements become further defined as a result of future Task Order awards, they may be incorporated into this IDIQ on an as needed basis to help meet future CDS support needs of the VA as they become more defined and/or refined during the course of contract performance.

The Contractor shall not provide personal services to support CDS for the Government in the course of this IDIQ. The Contractor shall primarily support the CDS Program Office within KBS, and as part of those duties may be required to coordinate with and share information with other inter-related KBS initiatives within CIDMO and VA.

This effort does not require the performing Contractor to develop, build, modify,or deploy any software application or code. No software will be developed or delivered as part of the effort’s requirements.

There are two overarching, major task areas for this effort, as shown in sub-sections 2.1 and 2.2 below.

Predefined CDS Knowledge Artifact Tasks For predefined CDS knowledge artifact tasks described in Section 5.1, Contractor shall perform tasks that relate specifically to creating/updating/enhancing/extending new and/or existing CDS artifacts, including knowledge research, clinical content creation or update, and clinical content representation.

Functional Category (i.e., not pre-defined) Tasks For functional CDS tasks which have not been completely defined and/or refined, the Contractor shall perform tasks not specifically related to CDS knowledge artifact creation but will instead provide CDS support to VHA, VA, and Federal partners across a broad range of programs and projects. Examples of the tasks to be performed under this task category include (but are not limited to) : 1) identifying and researching problems and knowledge gaps, reviewing literature, and proposing solutions for a variety of areas related to Knowledge Acquisition, Integration, and Management for CDS, and 2) providing technical writing and presentation expertise.

APPLICABLE DOCUMENTS

Applicable documents are listed below. Additional documents may be listed in individual Task Orders.

A. 44 U.S.C. § 3541, “Federal Information Security Management Act (FISMA) of 2002” B. Federal Information Processing Standards (FIPS) Publication 140-2, “Security Requirements For Cryptographic Modules” C. FIPS Pub 201, “Personal Identity Verification of Federal Employees and Contractors,” March 2006 D. 5 U.S.C. § 552a, as amended, “The Privacy Act of 1974” E. Public Law 109-461, Veterans Benefits, Health Care, and Information Technology Act of 2006, title IX Information Security Matters F. 10 U.S.C. § 2224, "Defense Information Assurance Program" G. 42 U.S.C. § 2000d “Title VI of the Civil Rights Act of 1964” H. Department of Veterans Affairs (VA) Directive 0710 Personnel Security and Suitability Program dated May 18, 2007 (https://www.voa.va.gov/) I. Department of Veterans Affairs (VA) Directive 6102 (Internet/Intranet Services) (https://www.voa.va.gov/) J. Department of Veterans Affairs (VA) Handbook 6102 (Internet/Intranet Services) (https://www.voa.va.gov/) K. Health Insurance Portability and Accountability Act (HIPAA); 45 CFR Part 160, 162, and 164; Health Insurance Reform: Security Standards; Final Rule dated February 20, 2003 L. VHA Security Handbook 1600.01, Business Associate Agreements (https://www.voa.va.gov/) M. 36 C.F.R. Part 1194 “Electronic and Information Technology Accessibility Standards,” July 1, 2003 N. Office of Management and Budget Circular A-130, “Management of Federal Information Resources’, November 28, 2000 O. U.S.C. Section 552a, as amended P. Title 32 CFR 199, “Civilian Health and Medical Program of the Uniformed Services (CHAMPUS)” Q. An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, October 2008 R. Sections 504 and 508 of the Rehabilitation Act (29 U.S.C. Section § 794d), as amended by the Workforce Investment Act of 1998 (P.L. 105-220), August 7, 1998 S. Homeland Security Presidential Directive (12) (HSPD-12), August 27, 2004 T. Department of Veterans Affairs (VA) Directive 6500, “Managing Information Security Risk: VA Information Security Program,” September 20, , 2012 U. VA Handbook 6500, “Risk Management Framework for VA Information Systems – Tier 3: VA Information Security Program,” March 10, 2015 V. VA Handbook 6500.1, “Electronic Media Sanitization,” March 22, 2010.

W. VA Handbook 6500.2, “Management of Data Breaches Involving Sensitive Personal Information (SPI)”, January 6, 2012 X. VA Handbook 6500.3, “ASSESSMENT, AUTHORIZATION, AND CONTINUOUS MONITORING OF VA INFORMATION SYSTEMS,” February 3, 2014.

Y. VA Handbook, 6500.5, Incorporating Security and Privacy in System Development Lifecycle,” March 22, 2010 Z. VA Handbook 6500.6, “Contract Security,” March 12, 2010 AA. Office of Information and Technology (OI&T) ProPath Process Methodology (https://www.voa.va.gov/) NOTE: In the event of a conflict, OI&T ProPath takes precedence over other processes or methodologies.

AB. National Institute of Standards and Technology (NIST) Special Publication 800-53, “Recommended Security Controls for Federal Information Systems and Organizations”(https://www.voa.va.gov/) AC. Veteran-focused Integrated Process (VIP) portal (https://www.voa.va.gov/DocumentView.aspx?DocumentID=4371 ) AD. Federal Travel Regulation (FTR) (www.gsa.gov/federaltravelregulation) AE. Technical Reference Model (TRM) (https://www.oit.va.gov/services/trm/ ) AF. Federal Segment Architecture Methodology (FSAM) v1.0, December 2008 AG. National Institute Standards and Technology (NIST) Special Publications 800 series AH. VA Directive 6508, Implementation of Privacy Threshold Analysis and Privacy Impact Assessment, October 15, 2014 AI. VA Directive 6300, Records and Information Management, February 26, 2009 AJ. VA Directive 6300, Records and Information Management, February 26, 2009 AK. VA Handbook, 6300.1, Records Management Procedures, March 24, 2010 AL. OMB Memorandum, “Transition to IPv6”, September 28, 2010 AM. Health Level 7 (HL7) Standard: “Clinical Decision Support Knowledge Artifact Specification, Release 1.3, Draft Standard for Trial Use (DSTU), July 2015, http://www.hl7.org/implement/standards/product_brief.cfm?product_id=337 AN. Project Summary for FHIR-Based Quality Framework (CQF on FHIR), http://www.hl7.org/special/committees/projman/searchableprojectindex.cfm?action=edit&ProjectNumber=1234 (appeared on HL7 May 2016 Ballot) AO. A Roadmap for National Action on Clinical Decision Support June 13, 2006, https://www.amia.org/public-policy/reports-and-fact-sheets/a-roadmap-for-national-action-on-clinical-decision-support AP. Clinical Quality Framework (CQF) Implementation Guide https://www.hl7.org/fhir/2016Sep/clinicalreasoning-module.html

GENERAL REQUIREMENTS

The Contractor shall provide and/or acquire the services, hardware, and software considered necessary to perfiorm the the requirements set forth in this PWS.

Contract Type The Government intends to award a multi-award Indefinite Delivery/Indefinite Quantity (IDIQ) contract. Individual Task Orders (TOs) shall be issued on a performance-based Firm-Fixed-Price (FFP) basis.

Period of Performance The ordering period for the IDIQ shall be for ten (10) years, and the effective period shall be for fifteen (15) years.

Any/all work performed at a Government site/facility shall not take place on Federal holidays or weekends unless directed by the Contracting Officer (CO).

Place of Performance The Government anticipates that tasks under this PWS shall be performed primarily at Contractor facilities. There is the possibility that work may be performed at remote locations or at VA facilities, but only with prior approval of the Contracting Officer’s Representative (COR). Work requirements with respect to place of performance may be delineated at the individual Task Order level as required.

Travel Travel shall be in accordance with individual Task Order requirements. Travel details must be provided to and approved by the Contracting Officer’s Representative (COR) or the Government designee prior to the commencement of travel. All travel shall be in accordance with the Federal Travel Regulations (FTR) and may be on a direct- reimbursable basis or FFP basis. OCONUS travel may require additional authorization and approvals as specified in the individual Task Order. The Government currently utilizes a system called Attendance and Cost Estimation System (ACES) for travel authorizations. The Contractor may be required to utilize the ACES system (or successor system as may be directed by the Government during contract period of performance) prior to traveling for work funded by any Task Orders awarded against this contract. Additional travel approvals may also be required prior to travel.

Sample of locations and estimated days of duration include the following:

Table 1: Sample Travel Locations for Contract Contractor travel within the local commuting area will not be reimbursed.

Materials, Equipment, and Facilities Government Furnished Property Government Furnished Property (GFP) which includes Government Furnished Material (GFM), Government Furnished Information (GFI), and Government Furnished Equipment (GFE) may be provided during the course of contract performance; any such items will be identified at the Task Order level as required.

VA may provide VA specific software as appropriate and required, to be specified at the individual Task Order level as needed. The Contractor may utilize VA provided software development and test accounts, document and requirements repositories and others as required for the creation, storage, maintenance, and delivery of enterprise terminology content. Contractors shall comply with VA security policies and procedures with respect to protecting sensitive data. See Section 10.0 for detailed security requirements.

Contractor-Acquired The Contractor shall acquire and/or provide any hardware and/or software required to accomplish required tasks when such items and/or assets, tools, etc. are not provided by the Government. Software integrity shall be maintained by the Contractor within the licensing agreement of the producer until such software is delivered to the Government, or otherwise disposed of in accordance with Government direction. See Section 10.0 for detailed security requirements.

Non-Developmental Items and Commercial Processes Non-Developmental Items (NDI), Commercial-Off-The-Shelf (COTS) and Government-Off-The-Shelf (GOTS) products shall be used to the maximum extent as is practicable. The Contractor shall apply commercially available and industry best processes, standards and technologies to the maximum extent possible.

Connectivity VA will provide the Contractor use of Virtual Private Network (VPN) as appropriate. The Contractor shall bear all costs related to its connectivity to VA through VPN. VA will provide the required account access accordingly. Other connectivity to VA systems may be authorized as deemed necessary, and may be further defined and /or specified at the individual Task Order leval as needed.

Facilities Work may be performed at either a Government or Contractor facility. Each Task Order shall delineate the facility requirements.

Government Facilities Certain Government office or laboratory space may be made available for performance of individual Task Orders. Contractors may be required to establish operations and support Government facilities and shall comply with VA and/or Federal certification and accreditation requirements. Such facilities shall be specified in the individual Task Order.

Contractor Facilities Personnel may perform at a Contractor facility or remote locations. Contractors may be required to establish operations and support Contractor facilities and shall comply with VA and/or Federal certification and accreditation requirements. Such facilities shall be specified in the individual Task Order.

Warranty Items acquired under this contract may require warranty protection. Any/all Commercial warranties for items, tools, solutions, etc. being used by the Contractor in order to perform this effort shall be transferred to the Government. The type of warranty and extent of coverage may be determined at the individual Task Order level, as required.

Marking, Handling, Storage, Preservation, Packaging, & Shipping The Contractor shall establish/maintain procedures for handling, storage, preservation, packaging, and shipping to protect the quality of products and prevent damage, loss, deterioration, degradation or substitution of products.

Export Control The Contractor shall comply with all applicable laws and regulations regarding export-controlled information and technology and shall not use, distribute, transfer or transmit technology (even if incorporated into products, software or other information) except in compliance with such laws and regulations. In addition, the Contractor shall plan for, obtain, and maintain any and all export licensing required to satisfy performance requirements set forth in this PWS as well as any/all PWS documents issued at the individual Task Order level. Enterprise and IT Framework

The Contractor shall support the VA enterprise management framework. In association with the framework, the Contractor shall comply with OI&T Technical Reference Model (One-VA TRM). One-VA TRM is one component within the overall Enterprise Architecture (EA) that establishes a common vocabulary and structure for describing the information technology used to create, operate, and maintain enterprise applications. One-VA TRM includes the Standards Profile and Product List that collectively serves as a VA technology roadmap. Architecture, Strategy, and Design (ASD) has overall responsibility for the One-VA TRM.

Where applicable, the Contractor’s solution shall support the latest Internet Protocol Version 6 (IPv6) requirements and compliance standards established by Federal Acquisition Regulation (FAR) and NIST for IPv6 for Federal Government Agencies. IPv6 technology must be included in all infrastructure and application design and development efforts.

The Contractor shall support VA efforts in accordance with the Veteran-focused Integrated Process (VIP) as directed by the program office. The Contractor shall use an incremental approach, including frequent delivery milestones that deliver new capabilities for stakeholders (including the program office and VA EHRM efforts) to evaluate.

When specified, the Contractor shall utilize ProPath, the process management tool that assists in the execution of a project (including adherence to VIP standards).

Additional frameworks may be specified at the individual Task Order level as required.

Enterprise Product Teams The Contractor may be required to serve as a member of, or provide Subject Matter Expertise to Integrated Product Teams (IPTs) or Integrated Business Teams (IBTs) within the VA. If required to perform these tasks, the scope of their role(s) and required tasks will be identified at the individual Task Order level. IPTs and IBTs are cross-functional teams that work collaboratively to create strategies and approaches to meet particular objectives. IPTs and IBTs bring together the principal stakeholders and focus efforts on establishing critical elements of all phases of the acquisition lifecycle.

Transition and Orientation Support The Contractor shall perform transition and orientation services (e.g. create Phase-In/Phase-Out Transition Plan) to insure continuity of services as specified in the individual Task Order. Transition and orientation support may include transitioning to Government or Contractor personnel, and details will be provided at the individual Task Order level when needed.

SPECIFIC REQUIREMENTS (i.e., predefined) The tasks and deliverables described below are specific in nature (i.e., predefined). Individual task orders may encompass more than one specific requirement listed below. Additional reporting, management, and meeting requirements (i.e., project management) may be required; any such additional requirements will be specified as additional tasks at the individual Task Order level as applicable. See section 6.1.

Please Note: Any task order issued may require the Contractor to interact with other independent Contractors, to be specified at the time of the task order, and utilize and review their work product as delivered to the Government.

CDS Knowledge Artifact Tasks Tasks listed in Sections 5.1.1 through 5.1.9 below apply to all CDS artfiact creation tasks shown in Sections 5.1.10 through 5.1.13, and may also apply to other tasks within this effort as designated by the Government at the individual Task Order level.

Some tasks required by the Government through individual Task Orders may have dependencies on other tasks in this IDIQ. Specific performance requirements will be determined and set forth at the individual Task Order level, to include any dependent tasks considered necessary for the specified tasks.

For example, if a Task Order requires the creation of a CDS artifact, then the tasks for clinical knowledge research and intervention design may also be deemed necessary for the creation of the CDS artifact. Yet at other times, certain related tasks may not be called out as part of a particular Task Order’s stated performance requirements, depending on the Government’s needs for that particular Task Order.

Requirement to Adopt Approriate CDS Knowledge Artifact Standard(s) at time of Task Order Award(s) For the purposes of this contract effort and as described in detail in Background Section 1.4, the Government intends to apply prevailing standard(s) for platform agnostic CDS artifacts over the life of the IDIQ. Previously, VA has applied the HL7 CDS KAS, currently Release 1.3, to the creation of CDS artifacts. Therefore, the Government shall inform the Contractor which standard or standard(s) to apply at the individual Task Order Level. While the standard(s) to be applied may vary over time, the Government shall not change the standard(s) during the life of an individual task order unless otherwise specified in the task order or as required by exigent circumstances which may require task order modification.

Regardless of which standard is used at any point in time, all CDS artifacts that are created for this contract must be updateable in a manner and form approved by the Government such as to comply with new standards or to meet changing clinical guidelines.

As part of this contract effort, the Contractor shall be required to work specifically both with the KBS Terminology Team and the KBS Terminology Contractor to create all terminology representation of clinical content required for each CDS artifact as specified within a Task Order issued under this CDS IDIQ, irrespective of the specific standard identified. The Contractor shall be responsible for identifying the proper model to represent a particular aspect of clinical content, subject to the Government’s policies and consent. The KBS Terminology Team shall be engaged to provide the necessary terminology artifacts to populate the identified model.

Similarly, the Contractor shall be required to work with the KBS Standards and Interoperatlity Team and/or the KBS Informatics Architecture Team and Contractor team(s) engaged in work for either or both of these KBS teams, as specified within individualTask Orders.

Formation and Function of SME Teams For tasks included in Sections 5.1.10, 5.1.11, 5.1.12, and/or 5.1.13 below, the Contractor shall work with subject matter experts (SMEs) as stated, including but not limited to clinical SMEs both internal and external to the VA as needed, to determine the specific content and design of each CDS knowledge artifact. These teams are referred to herein as “SME teams”.

The Government will provide a list of potential VA staff that the Government would like to invite to participate as an SME on an SME team for one or more efforts under Sections 5.1.10, 5.1.11, 5.1.12, and/or 5.1.13. To the extent possible, the Government will provide that roster within 2 weeks prior to the work beginning on a given CDS artifact in tandem with the approved Contractor Project Management Plan, and the Government will make initial introduction between the VA staff and the Contractor. However, the Contractor is responsible for contacting, scheduling, and communicating with SMEs via email and telephone and verifying their agreement to participate on the SME teams.

If no VA staff is available to participate or if insufficient VA staff is available, the Contractor shall independently provide the appropriate clinical SME(s) with the skills and experience to execute the work under the relevant PWS section.

The Contractor shall be required to have knowledge of direct patient care environments and clinical topics covered by the CDS artifacts, and demonstrate an understanding of the clinical setting, clinical practice, clinical informatics and prevailing standard(s).

For each CDS Artifact or set of CDS Artifacts ordered by the Government through individual Task Orders, the Contractor shall provide an appropriately staffed SME team. VA-identified SMEs will be participating on an advisory basis. Each SME team will consist of not fewer than two (2) SMEs, ideally representing more than one VA facility. An individual may serve on more than one SME team.