eCAMS Draft PWS.docx

PERFORMANCE WORK STATEMENT (PWS)

DEPARTMENT OF VETERANS AFFAIRS

Financial Services Center Financial Healthcare Service eCAMS Software Support

1.0 BACKGROUND

The Department of Veterans Affairs (VA), Financial Services Center (FSC) is authorized by the Government Management Reform Act of 1994 (Public Law 103-356) to provide common administrative support services on a reimbursable basis to VA and Other Government Agencies (OGA’s), as a Franchise Fund. The goals of the Franchise Fund organizations include:

· Lowering overhead costs

· Improving the quality and delivery of services

· Creating economies of scale

· Eliminating redundant services

· Being auditable VA-FSC requires a claims adjudication system that is used to adjudicate, process, and prepare for payment of healthcare claims submitted by healthcare providers. As a franchise organization, the FSC has existing and potential customers that can be migrated into the system.

FSC currently uses the Electronic Claims Adjudication System (eCAMS), provided by Client Network Services, LLC (CNSI), a commercial-off-the-shelf (COTS) claims adjudication system based on CNSI’s eCAMS HCE product line. The FSC uses eCAMS to adjudicate, process, and pay healthcare claims for four programs that support our healthcare processing product line: National Dialysis Services Contract (NDSC), ICE Healthcare Service Core and Other Government Agencies (OGA),(if contracted for), Non-Network Community Care Claims (CCNNC), and Veteran and Family Members Programs such as CHAMPVA, Spina Bifeda, Children of Women Vietnam Veterans and the Foreign Medical Program. Our current programs use’s Medicare-based rules and pricing; however, as a Franchise Fund, we may expand our program offerings which may involve more complex rules (all necessary configuration and implementation of such complex rules, if introduced, would be performed by VA personnel).

2.0 APPLICABLE DOCUMENTS

In the performance of the tasks associated with this Performance Work Statement, the Contractor shall comply with the following:

1. 44 U.S.C. § 3541-3549, “Federal Information Security Management Act (FISMA) of 2002”

2. “Federal Information Security Modernization Act of 2014”

3. Federal Information Processing Standards (FIPS) Publication 140-2, “Security Requirements for Cryptographic Modules”

4. FIPS Pub 199. Standards for Security Categorization of Federal Information and Information Systems, February 2004

5. FIPS Pub 200, Minimum Security Requirements for Federal Information and Information Systems, March 2016

6. FIPS Pub 201-2, “Personal Identity Verification of Federal Employees and Contractors,” August 2013

7. 10 U.S.C. § 2224, "Defense Information Assurance Program"

8. Carnegie Mellon Software Engineering Institute, Capability Maturity Model® Integration for Development (CMMI-DEV), Version 1.3 November 2010; and Carnegie Mellon Software Engineering Institute, Capability Maturity Model® Integration for Acquisition (CMMI-ACQ), Version 1.3 November 2010

9. 5 U.S.C. § 552a, as amended, “The Privacy Act of 1974”

10. Public Law 109-461, Veterans Benefits, Health Care, and Information Technology Act of 2006, Title IX, Information Security Matters

11. 42 U.S.C. § 2000d “Title VI of the Civil Rights Act of 1964”

12. VA Directive 0710, “Personnel Security and Suitability Program,” June 4, 2010, https://www.va.gov/vapubs/index.cfm

13. VA Handbook 0710, Personnel Security and Suitability Program, May 2, 2016, https://www.va.gov/vapubs/index.cfm

14. VA Directive and Handbook 6102, “Internet/Intranet Services,” August 5, 2019

15. 36 C.F.R. Part 1194 “Information and Communication Technology Standards and Guidelines,” January 18, 2017

16. Office of Management and Budget (OMB) Circular A-130, “Managing Federal Information as a Strategic Resource,” July 28, 2016

17. 32 C.F.R. Part 199, “Civilian Health and Medical Program of the Uniformed Services (CHAMPUS)”

18. NIST SP 800-66 Rev. 1, An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, October 2008

19. Sections 504 and 508 of the Rehabilitation Act (29 U.S.C. § 794d), as amended, January 18, 2017

20. Homeland Security Presidential Directive (12) (HSPD-12), August 27, 2004

21. VA Directive 6500, “VA Cybersecurity Program,” January 24, 2019

22. VA Handbook 6500, “Risk Management Framework for VA Information Systems – Tier 3: VA Information Security Program,” March 10, 2015

23. VA Handbook 6500.2, “Management of Breaches Involving Sensitive Personal Information (SPI)”, July 28, 2016

24. VA Handbook 6500.3, “Assessment, Authorization, And Continuous Monitoring Of VA Information Systems,” February 3, 2014

25. VA Handbook 6500.5, “Incorporating Security and Privacy into the System Development Lifecycle”, March 22, 2010

26. VA Handbook 6500.6, “Contract Security,” March 12, 2010

27. VA Handbook 6500.8, “Information System Contingency Planning”, April 6, 2011

28. VA Handbook 6500.11, “VA Firewall Configuration”, August 22, 2017

29. OI&T Process Asset Library (PAL), https://www.va.gov/process/ . Reference Process Maps at https://www.va.gov/process/maps.asp and Artifact templates at https://www.va.gov/process/artifacts.asp

30. One-VA Technical Reference Model (TRM) (reference at https://www.va.gov/trm/TRMHomePage.aspx)

31. VA Directive 6508, “Implementation of Privacy Threshold Analysis and Privacy Impact Assessment,” October 15, 2014

32. VA Handbook 6508.1, “Procedures for Privacy Threshold Analysis and Privacy Impact Assessment,” July 30, 2015

33. VA Handbook 6510, “VA Identity and Access Management”, January 15, 2016

34. VA Directive and Handbook 6513, “Secure External Connections”, October 12, 2017

35. VA Directive 6300, Records and Information Management, September 21, 2018

36. VA Handbook, 6300.1, Records Management Procedures, March 24, 2010

37. NIST SP 800-37 Rev 1, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, December 2018

38. NIST SP 800-53 Rev. 4, Security and Privacy Controls for Federal Information Systems and Organizations, January 22, 2015

39. OMB Memorandum, “Transition to IPv6”, September 28, 2010

40. VA Directive 0735, Homeland Security Presidential Directive 12 (HSPD-12) Program, October 26, 2015

41. VA Handbook 0735, Homeland Security Presidential Directive 12 (HSPD-12) Program, March 24, 2014

42. OMB Memorandum M-06-18, Acquisition of Products and Services for Implementation of HSPD-12, June 30, 2006

43. OMB Memorandum 04-04, E-Authentication Guidance for Federal Agencies, December 16, 2003

44. OMB Memorandum 05-24, Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and Contractors, August 5, 2005

45. OMB memorandum M-11-11, “Continued Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and Contractors, February 3, 2011

46. OMB Memorandum, Guidance for Homeland Security Presidential Directive (HSPD) 12 Implementation, May 23, 2008

47. Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance, December 2, 2011

48. NIST SP 800-116 Rev 1, Guidelines for the Use of Personal Identity Verification (PIV) Credentials in Facility Access, June 2018

49. OMB Memorandum M-07-16, Safeguarding Against and Responding to the Breach of Personally Identifiable Information, May 22, 2007

50. NIST SP 800-63-3, 800-63A, 800-63B, 800-63C, Digital Identity Guidelines, December 2017

51. NIST SP 800-157, Guidelines for Derived PIV Credentials, December 2014

52. NIST SP 800-164, Guidelines on Hardware-Rooted Security in Mobile Devices (Draft), October 2012

53. Draft National Institute of Standards and Technology Interagency Report (NISTIR) 7981 Mobile, PIV, and Authentication, March 2014

54. VA Memorandum, VAIQ #7100147, Continued Implementation of Homeland Security Presidential Directive 12 (HSPD-12), April 29, 2011 (reference https://www.voa.va.gov/documentlistpublic.aspx?NodeID=514)

55. IAM Identity Management Business Requirements Guidance document, May 2013, (reference Enterprise Architecture Section, PIV/IAM (reference https://www.voa.va.gov/documentlistpublic.aspx?NodeID=514)

56. VA Memorandum “Personal Identity Verification (PIV) Logical Access Policy Clarification,” July 17, 2019, https://www.voa.va.gov/DocumentView.aspx?DocumentID=4896

57. Trusted Internet Connections (TIC) Reference Architecture Document, Version 2.2, Federal Interagency Technical Reference Architectures, Department of Homeland Security, June 19, 2017, https://www.dhs.gov/sites/default/files/publications/TIC_Ref_Arch_v2.2_2017 .pdf

58. OMB Memorandum M-08-05, “Implementation of Trusted Internet Connections (TIC), November 20, 2007

59. OMB Memorandum M-08-23, Securing the Federal Government’s Domain Name System Infrastructure, August 22, 2008

60. VA Memorandum, VAIQ #7497987, Compliance – Electronic Product Environmental Assessment Tool (EPEAT) – IT Electronic Equipment, August 11, 2014 (reference Document Libraries, EPEAT/Green Purchasing Section, https://www.voa.va.gov/documentlistpublic.aspx?NodeID=552)

61. Sections 524 and 525 of the Energy Independence and Security Act of 2007, (Public Law 110–140), December 19, 2007

62. Section 104 of the Energy Policy Act of 2005, (Public Law 109–58), August 8, 2005

63. Executive Order 13834, “Efficient Federal Operations”, dated May 17, 2018

64. Executive Order 13221, “Energy-Efficient Standby Power Devices,” August 2, 2001

65. VA Directive 0058, “VA Green Purchasing Program”, July 19, 2013

66. VA Handbook 0058, “VA Green Purchasing Program”, July 19, 2013

67. Office of Information Security (OIS) VAIQ #7424808 Memorandum, “Remote Access”, January 15, 2014, https://www.voa.va.gov/DocumentListPublic.aspx?NodeId=28

68. Clinger-Cohen Act of 1996, 40 U.S.C. §11101 and §11103

69. “Veteran Focused Integration Process (VIP) Guide 3.2”, December 2018, https://www.voa.va.gov/DocumentView.aspx?DocumentID=4371

70. VA Memorandum “Proper Use of Email and Other Messaging Services”, January 2, 2018, https://www.voa.va.gov/DocumentListPublic.aspx?NodeId=28

3.0 SCOPE OF WORK

The Contractor shall provide VA-FSC with software that meets the VA-FSC requirements identified in this PWS. The Contractor shall provide either a perpetual license allowing unlimited use of the software product in perpetuity or a transaction-based license that can transition to a perpetual license if claim volume exceeds 15 million total transactions; as well as configuration, implementation, integration, testing, deployment of software, training, maintenance, and technical support. The Contractor shall follow an Agile Methodology and follow VIP established by OI&T Enterprise Program Management Office (EPMO). The Contractor shall also provide quality improvement services throughout the duration of the contract.

4.0 PERFORMANCE DETAILS

4.1 PERFORMANCE PERIOD

The period of performance (POP) shall consist of one 24-month base period from date of award, followed by three (3) 12-month option periods.

When work is performed at a VA facility, contract personnel shall maintain a work schedule that coincides with the schedule of the VA-FSC organizations they support. Normal Federal Government workdays are between core hours of 0600 (6:00 AM) Central Time (CT) and 1800 (6:00 PM) CT.

On occasion, Contractor personnel may be required to provide services outside of normal hours of duty. When this happens, Contractor personnel shall comply with the VA-FSC's requirements. Contractor personnel shall not work during off-duty hours unless authorized in advance by the Contracting Officer's Representative (COR). The COR and the Contractor shall mutually agree upon all deviations to the schedule.

Any work at a Government site shall not take place on Federal holidays or weekends, unless directed by the Contracting Officer (CO). If required, the CO may require work during holidays and/or weekends. At a minimum, at least one Federal Government employee whose duties are relevant to the scope of this PWS must be present whenever Contract personnel perform work defined in this PWS at a VA facility.

There are 11 Federal holidays set by law (USC Title 5 Section 6103) that VA follows:

Under current definitions, five are set by date:

New Year's Day, January 1 Juneteenth, June 19 Independence Day, July 4 Veterans Day, November 11 Christmas Day December 25 If any of the above falls on a Saturday, then Friday shall be observed as a holiday. Similarly, if one falls on a Sunday, then Monday shall be observed as a holiday.

The other six are set by a day of the week and month:

Martin Luther King's Birthday, Third Monday in January Washington's Birthday, Third Monday in February Memorial Day, Last Monday in May Labor Day, First Monday in September Columbus Day, Second Monday in October Thanksgiving, Fourth Thursday in November

4.2 PLACE OF PERFORMANCE

The Contractor’s software shall be installed at the VA-FSC facility in Austin, Texas. Most tasks under this PWS shall be performed at Contractor facilities. The Contractor shall identify the Contractor’s place of performance in their proposal submission. Work at the VA-FSC government facility will be allowed as directed by VA-FSC program management staff and/or the COR; however, no more than 10 contractor personnel will be authorized to work at the VA-FSC facility at any given time.

4.3 TRAVEL

Costs for all travel associated with the tasks specified in section 5.0 (Specific Task and Deliverables) of this PWS shall be borne by the Contractor and shall not be separately reimbursed by the Government.

5.0 SPECIFIC TASKS AND DELIVERABLES

The Contractor shall perform the following:

5.1 IMPLEMENTATION AND PROJECT MANAGMENT

5.1.1 CONTRACTOR PROJECT MANAGEMENT PLAN

The Contractor shall deliver a Contractor Project Management Plan (CPMP) that lays out the Contractor’s approach, timeline and tools to be used in execution of the contract. The CPMP should take the form of both a narrative and graphic format that displays the tasks, sub-tasks, schedule and timelines, milestones, resource support, and risks. The CPMP shall specifically address infrastructure requirements for all environments (Production, Pre-Production, Staging, Development, Testing, and User Testing). The CPMP shall also include how the Contractor shall coordinate and execute planned, routine, and ad hoc data collection reporting requests as identified within the PWS. The Contractor shall update and maintain the VA PM approved CPMP throughout the period of performance. The schedule and timelines shall be segregated by period, i.e. one initial two-year period plus each of three option periods, such that there is no overlap in periods for any scheduled activity, i.e. successful completion of work identified under any one period is not contingent on the exercise of any option period. The Contractor shall plan for 90-day period for VA testing to support production release and “go live” for each program offering. The Contractor shall update and maintain the VA Program Management approved CPMP, and submit the updated plan monthly, throughout the period of performance. The contractor shall submit the initial CPMP no later than 2 business days prior to the PAOC.

The monthly update to the CPMP shall cover all work completed during the month preceding the month during which the update is delivered, plus work planned for the month in which the update is delivered and any subsequent period within six months of the date of delivery. The update shall also identify any problems that arose and either a description of how the problems were resolved, or suggested resolutions, if problems were not resolved during the reporting period. If problems have not been completely resolved, the Contractor shall provide an explanation including their plan and timeframe for resolving each issue. The update shall also include any change in Contractor staff involved in the work identified in this PWS. The Contractor shall monitor performance against the CPMP and report any deviations. The Contractor is required to communicate problems and issues to the VA within three calendar days of discovery, to ensure issues identified on the report are transparent to both parties and to prevent escalation of outstanding issues.

Deliverable:

A. Contractor Project Management Plan

5.1.2 POST AWARD ORIENTATION CONFERENCE (PAOC)

The Contractor shall participate (in person or virtual at Contractor’s discretion) in the PAOC at the VA-FSC in Austin, TX within seven calendar days after contract award, and cover the following information during the PAOC:

a. Details regarding Tasks, Subtasks, Timelines, and the Delivery Schedule for the Contract Project Management Plan

b. Names and credentials for all Contractor resources who will participate in contract implementation (by Contractor)

c. Schedule for meetings with FSC Team members, Government counterparts to Contractor staff, Contractor staff, and Data Contacts resources.

d. FSC Onboarding staff shall discuss Onboarding and Offboarding processes.

The Contractor shall document the PAOC meeting minutes detailing what was discussed, list of attendees, expectations of Contractor, expectations of VA-FSC, and any actions required of each party.

Deliverable:

A. PAOC Meeting Minutes

5.1.3 SOFTWARE PRODUCT/LICENSE

As stated in the background section, the FSC currently services a number of customers and, as a Franchise organization, it has the ability to service additional customers with the healthcare claim processing product line. In order to enable and provide expansion capability, the software shall be capable of scaling to an estimated annual volume of 30 million claims. As the FSC’s customer base expands, the software will need to continue to scale to meet the performance requirements outlined in section 5.4.2.

Deliverable:

A. Software Product/License

5.1.4 PERPETUAL SOFTWARE PRODUCT/LICENSE

The Contractor shall provide the software product meeting the requirements specified below in section 5.4.2 and its subparagraphs and allow VA-FSC unlimited use of the software product in perpetuity. Unlimited use is defined as unlimited number of users and an unlimited number of medical claims processed.

5.2 OPERATIONS AND MAINTENANCE (O&M)

5.2.1 SOFTWARE TECHNICAL SUPPORT

The Contractor shall provide software technical support, such that the software product is operable at all times. The Contractor shall provide support services 24 hours a day seven days a week 365 days a year (366 days within a leap year) throughout the period of performance. Contractor shall acknowledge requests for technical support within one (1) hour of receiving requests for support from VA-FSC; and shall acknowledge receipt of the request via email to the COR. Contractor shall commence remediation of identified problems within 24 hours of receiving the request. The Contractor shall record all service calls in a Technical Services Log, which is to be delivered electronically to the VA-FSC COR no later than the fifth day of each month after contract award. A record of all service calls for the month shall be copied into a Technical Services Report, to be delivered to the VA-FSC COR no later than the fifth day of each month after contract award. The Technical Services Log and Technical Services Report shall include a description of each problem, when communication of the problem was received by the Contractor, a description of the resolution, and the date and time when the problem was considered completely resolved.

While the FSC Program Management Team has primary responsibility, the Contractor shall assist the FSC Program Management Team, as needed, with the following O&M tasks:

· User access administration

· Application daily monitoring

· Daily production status updates

· VA Configuration Management and VA Change Control Board requests

· Installation support and post deployment validation of application

· Database and architecture support Deliverable:

A. Technical Services Report and Log (monthly)

5.2.2 PATCHES FOR BUGS AND ISSUES

If at any time the software product becomes inoperable or requires maintenance, whether discovery is by the Contractor or VA; the Contractor shall provide necessary patches to the software product in a timely manner to ensure its continuous operation; in accordance with the functionalities, capabilities, and requirements defined herein. Security vulnerabilities are categorized as critical, high, medium and low. In-depth definitions are:

· Critical: A successful attack would expose Sensitive Personal Information (SPI), Personally Identifiable Information (PII), or Protected Health Information (PHI) internally or externally to unauthorized people.

· High: A successful attack would seriously impact system confidentiality, availability, integrity, or authentication

· Medium: A successful attack would moderately impact system confidentiality, availability, integrity, or authentication.

· Low: A successful attack would minimally impact system confidentiality, availability, integrity, or authentication.

The Contractor shall remediate all critical and high security vulnerabilities (i.e., a backdoor portal is discovered during a system scan) required to secure Office of Information Security approval prior to the initial system deployment to the production environment. The Contractor shall also, remediate all critical and high security vulnerabilities within 15 calendar days of being informed of the identified vulnerability throughout the period of performance. The Contractor shall remediate all medium and low security vulnerabilities (discovered during a system scan) required to secure Office of Information Security approval prior to the initial system deployment to the production environment. The Contractor shall also remediate all medium vulnerabilities within 30 days and low security vulnerabilities within 45 calendar days of being informed of the identified vulnerability throughout the period of performance. If a vendor needs more time than prescribed to remedy a software bug or issue, the vendor shall notify the COR and contracting officer with the appropriate rationale and seek their concurrence for the delay.

The Contractor shall provide the VA-FSC Customer with a patch for a software bug or issue that negatively affects its performance; within 15 calendar days of being informed by the VA-FSC Customer of performance problems with the software.

The Contractor shall inform the VA-FSC Customer of readiness of the software patch within two calendar days of its creation.

The Contractor shall deliver the software patch to the VA-FSC Customer within four calendar days of having informed the VA-FSC Customer of its readiness.

5.2.3 SOFTWARE UPDATES AND QUALITY IMPROVEMENT

The Contractor shall perform ongoing quality improvement of the software throughout the entire life of the contract, by continually seeking ways to improve the software product, and integrate the improvements into the configured software being utilized by VA-FSC. Improvements shall include offering solutions to processing problems and concerns, to ensure VA-FSC is always adjudicating and paying healthcare claims in the most efficient and effective ways possible. Specific areas include the following:

a. Member Management and Eligibility

b. Benefit Administration

c. Provider Management

d. Fee Schedule and Contract Management

e. Authorizations and Referrals

f. Claims Adjudication and Processing

g. Customer Management

h. Accounts Payable

i. Financials

j. Correspondence

k. Reporting

l. Security and Audit Trails

m. Data Exchange Services

n. Ability to Scale up to Support Large Claims Volumes

o. Implementation and Configuration Services

p. Training Services

q. Technical Support and Configurable Software Maintenance Services

r. Support Services for Customization of Software The Contractor shall communicate quality improvements to the COR via email correspondence. The COR will coordinate such efforts with the VA-FSC Program Management team to arrange for incorporation and implementation of the improvements to the system.

The Contractor shall ensure all customization features and functionalities performed for VA-FSC are incorporated in all subsequent software updates and upgrades.

The Contractor shall release updates in compliance with new or modified federal mandates at least three months prior to the compliance date stated in the Federal Register.

The Contractor shall inform VA-FSC Program Manager of all software product updates within 10 calendar days of the update.

The Contractor shall have 20 calendar days to technically integrate the updated software and commence providing technical support for the updated software.

The Contractor shall provide the VA-FSC Program Manager or COR with a migration/upgrade plan within 30 days of contract award and update it as changes occur.

The Contractor shall provide the VA-FSC Program Manager or COR with release notes for all changes.

The Contractor shall provide to the Government, in conjunction with the Contractor’s release schedule to licensed customers, their software updates, including all related documentation for these software updates (e.g., release notes).

Deliverables:

A. Migration / Upgrade Plan B. Release Notes

5.3 CHANGE REQUESTS (CR) BASE AND ALL OPTION YEARS AS WELL AS OPTIONAL TASKS

Upon identification of a change request (CR), the Government shall provide a summary of the problem and required services. The Contractor shall provide a proposed response for review and approval from the VA COR, detailing the proposed labor mix and hours to accomplish this task. If the COR approves the CR, the contractor shall develop and implement those approved change requests and new initiatives using the change request methodology and in accordance with the requirements in paragraph 5.3 and its subparagraphs.

The Government will provide the approved requirements 10 business days prior to the first day of each month. Upon approval of the requirements by the Government, Contractor will recommend a release timeline based on the Level of Effort (LOE) and the resources required to support the release.

Contractor shall update all system documents, user documents and training documents based upon the change request to be implemented.

Deliverables:

A. CR Proposed Response B. Code Release (if needed) C. Implementation Documentation

5.4 ADDITIONAL TASKS

5.4.1 CODE RELEASES

Contractor shall conduct monthly code releases for all O&M and change requests during the first week of each month. The VA program manager, COR and Contractor shall approve any changes to this schedule.

Any code changes shall not invalidate the Government’s license to use their software.

5.4.2 SYSTEM FEATURES AND CAPABILITIES

The contractor shall ensure eCAMS maintains the following functionality/capability:

5.4.2.1 SOFTWARE LICENSE

Any Contractor changes/updates to the software shall not invalidate the existing software license between the Government and the Contractor.

5.4.2.2 MEMBER MANAGEMENT AND ELIGIBILITY

a. Ability to import and real-time (synchronous exchange) integration of member data from external data sources.

b. Allows automatic adding of a new member from the receipt of claim or authorization data via an Electronic Data Interchange (EDI) or other electronic transmission. The software shall support configuration to automatically pend member records and associated claims for review. The software shall allow additional user defined fields to be added to the member/eligibility records.

c. Ability to search for a member based on name, social security number, unique identification numbers, treatment facility, and/or any other fields associated with the member/eligibility record.

d. Allows multiple concurrent health plan eligibilities.

e. Can be configured to limit access to a select group of members (such as VA employees, high profile personnel, and those requiring access to sensitive data), as defined by VA-FSC staff; such that only certain users would be authorized to view member associated data.

f. Can be configured to limit the visibility of sensitive data for a select group of members; and adds users viewing such data to an auditable log.

g. Can track and store dental data, patient conditions, and clinical history, which can be added manually, imported from member data, or added from claim details.

h. Can store Release of Information (ROI) details for a member, which defines the type of information that can be released about a member.

5.4.2.3 BENEFIT ADMINISTRATION

a. Supports an unlimited number of benefit plans; and allows members to be assigned to more than one benefit plan concurrently, over multiple programs.

b. Can be configured to automatically determine the appropriate benefit plan to be used during adjudication, if a member is assigned to more than one benefit plan.

c. Can be configured to track copayments, deductibles, coinsurance, limits, maximums, and exclusions for each member, by benefit plan or program; link member data with subscriber information; and calculate a catastrophic cap per member or family.

d. Ability to track secondary and tertiary insurance coverage.

e. Ability to establish unique description names for benefit plans.

f. Allows benefit plans that utilize a range of procedures and/or diagnosis codes that are either excluded from the plan; or have different or additional copayments, co-insurance, or limits.

g. Allows the creation of diagnosis or procedure code groups to be assigned to benefit plans.

5.4.2.4 PROVIDER MANAGEMENT

Note: The term “provider” or “service provider” means an individual healthcare provider, a Medical Group, or a Medical Network.

a. Allows importing and real-time (synchronous exchange) integration of provider data from external data sources.

b. Allows automatic adding of a new provider from the receipt of claim or authorization data via an Electronic Data Interchange (EDI) or other electronic transmission. The software shall support configuration to automatically pend provider records and associated claims for review.

c. Allows the establishment of service providers practicing as individuals, Medical Groups consisting of one or more providers, and Networks consisting of grouped service providers.

d. Allows tracking of multiple provider servicing locations.

e. Allows storage and tracking of a National Provider Identification Number (NPI) for a service provider.

f. Allows storage and tracking of a Federal Tax Identification Number (TIN) for a service provider.

g. Ability to receive information from an external data source about sanctioned providers and flagging/pending those providers from use in the software. The software shall record specific dates of sanctioned providers, as necessary.

h. Allows provider negotiated contracts including fee schedules, capitation agreements and other carve-outs.

i. The software shall provide an Application Program Interface (API) for exchange of data between the software, existing interfaces, and external web portals.

5.4.2.5 FEE SCHEDULE AND CONTRACT MANAGEMENT

a. Able to administer multiple payers, unlimited benefit plans, and unlimited fee schedules; and utilize more than one fee schedule to adjudicate a claim.

b. Uses the International Classification of Diseases (ICD) ICD-10-CM code, Current Procedural Terminology (CPT) codes and Healthcare Common Procedure Coding Software (HCPCS) codes for the year in which the care was given. The software shall implement new codes or code set versions at regular intervals (as specified by the appropriate agency) or as they become available.

c. Provides a tool or utility that allows the end-user the ability to import code sets as updates become available. Code sets required at a minimum are: ICD-10-CM, ICD-10-PCS; CPT; HCPCS; DRG; APC; CDT; CARC; RARC; Taxonomy, and user-defined code sets.

d. Supports integration to or solution inherently maintains groupers/pricers such as Resource-Based Relative Value Scales (RBRVS); Medicare Physician Fee Schedule (MPFS) and Usual, Customary and Reasonable (UCR) fee schedules; Outpatient Prospective Payment System (OPPS); Ambulatory Surgical Center (ASC); End Stage Renal Disease (ESRD); Long Term Care (LTC); Home Health Prospective Payment System (HH PPS); Skilled Nursing Facility (SNF); Inpatient Rehabilitation Facility Prospective Payment System (IRF PPS); Inpatient Prospective Payment System (IPPS); Inpatient Psychiatric Facility Prospective Payment System (IPF PPS); Durable Medical Equipment (DME); Federally Qualified Health Center Prospective Payment System (FQHC PPS); ambulance pricing, anesthesia pricing, clinical lab pricing; per diem pricing; percentage of billed charges; and flat rate pricing.

e. Can perform code grouping, editing, and pricing with the ability to configure claim dispositions based on edits.

f. Allows the linking of fee schedules to providers’ and members’ benefit plans.

g. Allows the ability for a contract to be copied, modified, and saved in order to easily create multiple contracts.

h. Can support Centers for Medicare and Medicaid Services (CMS) pricing rules such as Multiple Surgical Procedures reduction, Multiple Endoscopic Procedures reduction, global billing, modifiers, and Carrier Priced codes.

i. Can support ‘lesser of’ pricing comparisons and select the correct payment contract.

j. Can leverage multiple criteria such as Provider ID, Provider Specialty, Type of Bill, Practice Location, Benefit Plan, Claim Form Type, Network, or Dx code to determine the appropriate payment contract.

k. Can utilize a hierarchy of fee schedules within a payment contract and use multiple to pay a single claim.

5.4.2.6 AUTHORIZATIONS AND REFERRALS

a. Tracks authorized care to the location that authorized the care, and tracks authorizations and the cost of care to the authorizing location.

b. Can be configured to assign a valid obligation number based on authorization data, such as year, authorizing location, benefit plan, provider, network, or category of care.

c. Allows importing of authorization/referral data from external data sources. The software shall support importing authorizations in various formats, such as HL7 and SOAP XML.

d. The software shall provide an API for exchange of data between the software, existing interfaces, and external web portals.

e. Allows the business user to configure different claim/authorization matching business rules for different claim types or benefit plans.

5.4.2.7 DATA INPUT, CLAIMS INTAKE, AND DATA ACCESSIBILITY

a. Allows claim data input from various sources including EDI, Optical Character Recognition (OCR), and manual data entry.

b. Can store hyperlinks to electronic documents or images in multiple ‘entities’ (such as member, claim, provider, and authorization) so this information can be viewed when clicked.

c. Can be easily navigated and cross-referenced, such that entities referenced in any object can be drilled down to a hyperlink that opens that entity without having to navigate back to the main screen.

d. Claims software shall support import and ingestion from the existing EDI platform for the following X12 5010 administrative transaction sets:

i. Import of 837I; 837P; 837D claim files

ii. Import of 275 attachments – operating notes

e. Claims software shall support creation and export to the existing EDI platform for the following X12 5010 administrative transaction sets:

i. Creation of 835 payment files

ii. Creation of 277 claims status response, 277 request for additional information and 277CA response files

f. Allows update of the X12 administrative transaction sets to the next HIPAA mandated version.

5.4.2.8 WORK ASSIGNMENTS AND WORKFLOW

a. Consists of a user-friendly, graphical user interface screen, to manage workloads and predefined work queues.

b. Can support user-defined work queues for use in assigning work and managing workflows.

c. Can assign claims for adjudication and processing to individual users and push those claims to the user to which they have been assigned.

d. Allows supervisors to assign specific items to an individual or queue, and the ability to pull them from and/or reassign those items to another individual or queue.

e. Capable of managing workflow, which can include claims, members, providers, tickets, appeals, and documents.

5.4.2.9 CLAIMS ADJUDICATION

a. Shall adjudicate institutional, professional, and dental claims.

b. Ensures medical claims are adjudicated in accordance with current National Correct Coding Initiative (NCCI) edits and other industry standard edits.

c. Allows the business user to define criteria to identify duplicate claims and determine claim disposition.

d. Capable of matching an authorization/referral with a claim and pairing the two together during claim adjudication.

e. Can match authorizations at either the Claim or Claim Line level.

f. Capable of processing a unique claim based upon user defined claim criteria and/or benefit plan business rules.

g. Allows real-time (synchronous exchange) claim adjudication or batch claim adjudication. Batch claim adjudication can be pre-defined by specific criteria or at run time.

h. Capable of performing line-item adjudication and allow different service types on one claim to be paid, based on different payment methodologies.

i. Allows administrative business users to add, modify, and delete custom claim edits.

j. Can be configured to identify provider submitted adjustments, voids, and cancels; and send them to a separate work queue.

k. Allows user to resolve adjudication exceptions/pends, and override edits to claims.

l. Capable of allowing a user to reverse, adjust, or re-open a previously finalized claim.

m. Capable of tracking overpayments and supporting offsets.

n. Applies Coordination of Benefit rules during adjudication at the claim or line level.

o. Allows the application of other insurance coverage, such as home owners, automotive, workers compensation, State or local government programs; as applicable.

p. Has User Defined Fields that shall apply rules and reason codes during adjudication. The User Defined Fields can be set on multiple entities (such as Provider, member, authorization, and Claim).

q. Can perform mass adjustments of claims. The system shall allow the user to define criteria to identify claims to be adjusted, such as: member(s), Provider(s), Fee Schedule(s), Payment Contract(s), Benefit Plan(s), etc. The system shall provide the adjusted results prior to being committed and allow the user to review prior to execution.

r. Can adjudicate and provide either claim level or line level Pricing and reason codes.

s. Stores and makes transparent to the user all adjudication rules, pricing details, exceptions and overrides that were applied to the claim or claim line.

5.4.2.10 CUSTOMER MANAGEMENT

a. Allows a seamless integration with enterprise content management software via Content Management Interoperability Services (CMIS) standards.

b. Able to interface with a COTS Customer Relationship Management (CRM) system via web services in a Service Oriented Architecture (SOA) environment.

5.4.2.11 FINANCIALS AND ACCOUNTS PAYABLE

a. Able to generate an explanation of benefits or pricing and generate a file with EOB/EOP data to be integrated with an existing capability.

b. Capable of processing returned checks or Electronic Funds Transfer (EFT) payments from providers and adjust appropriate claims for immediate reprocessing.

c. Can associate an obligation to a claim, based on either the obligation defined on the Authorization or by utilizing claim criteria to map to an obligation.

d. Capable of integrating with a COTS financial accounting software.

e. Capable of creating a payment file that consists of payer information, payment and suspension amounts, Explanation of Benefits (EOB)/Explanation of Payment (EOP) advice, invoice or claim line-item detail, payment obligation detail, accounting line data, and fiscal year; all of which will be imported into an existing accounting software interface.

5.4.2.12 CORRESPONDENCE

a. Allows for the import of form letters from varying formats; at a minimum, these formats shall include Microsoft Word and Adobe PDF.

b. Able to select specific form letters automatically based on invoking business rules that trigger certain events. For example, if a claim is received and the member is determined not eligible for coverage; a specific form letter would be automatically selected and sent to both the provider and ineligible member.

c. Allows correspondence to be delivered to the appropriate recipient via hard copy, facsimile, or a method whereby the intended recipient is advised they have correspondence.

d. Allows integration of correspondence to a document management software system, and links to appropriate documentation associated with a member, claim, appeal, or other correspondence associated to a specific member. The integration shall link to the appropriate information, make it available in the application or in another window, and not force a log-in to a secondary application.

e. Supports a web-based portal for correspondence to members; and allows members correspondence capabilities via hard copy, facsimile, or e-mail.

f. Allows correspondence to be delivered to the appropriate recipient via secure email; and that allows the recipient to log in to a secure web-based service to obtain his or her correspondence.

5.4.2.13 DATA STORAGE AND DATA MANAGEMENT

a. Contains an Operational Data Store (ODS) to support efficient transaction processing and reporting capabilities.

b. VA and OGA information shall not be co-mingled.

c. Can identify and segregate data per FSC customer/lines of business.

d. Can allow standard reporting in the following major categories: claims/episodes of care, membership, authorizations, providers, and case management from the Operational Data Store.

e. Allows data extracts and data mirroring in the ODS, for reporting and analytical use.

f. Capable of supporting Extract, Transform, Load (ETL) that allows the movement of data between databases; and allows data to be extracted from the ODS by external VA entities.

g. Able to extract data from the transactional database to update the ODS; in such a manner as to not negatively impact production performance.

h. ODS capability shall support Online Analytical Processing (OLAP) for reporting.

i. Can be configured to allow the export of data into other analytical tools such as Excel, Access, and/or Adobe/PDF; and allows for a user-defined delimited export.

j. Capable of updating the ODS with data from the transactional database, a minimum of once a day.

k. Does not transmit to or store data at an offshore location. For the purposes of this contract, offshore is defined as being any location outside the United States, its possessions, and Puerto Rico.

5.4.2.14 REPORTING

a. Can monitor and track processor productivity, performance, and audits; and provide resulting metrics in ad hoc reports or on a role-based dashboard.

b. Can be configured to allow external tools similar to SQL Reporting Services, or Crystal Reports for ad hoc and custom reporting.

c. Can be configured to permit clinical, financial, and actuarial reporting.

d. Can be configured to allow multiple users to generate reports simultaneously, without degradation of system performance.

e. Can be configured to allow reporting of types of claims processed, claims processed over a specific time, processes worked, and who worked them.

f. Can be configured to ensure the average time it takes to generate reports shall not exceed two minutes per report.

5.4.2.15 SECURITY AND AUDIT TRAILS

a. Complies with the Federal Information Security Management Act (FISMA), National Institute of Standards and Technology (NIST), Federal Information Processing Standard (FIPS) 200, and related VA security control requirements commensurate with the FIPS 199 configurable software security categorization.

b. Complies with a High Impact security categorization level.

c. Database and web interfaces comply with all VA security and privacy standards.

d. Minimum security controls are integrated into the software contained in the VA-approved High Security Controls baseline.

e. Security controls are implemented in accordance with the provisions of a VA-approved software development life cycle.

f. Can provide user role-based security for accessing the application, down to the individual fields that users are permitted to view or modify.

g. Designed to flag a certain percentage of claims per user, based on that user’s skill level or other measurable criteria, which are subject to quality assurance audit.

h. Initially requires a user to be authorized to access the application through the operating software and indicate a specific user role as defined in the application.

i. Contains a security module that defines a user’s access to specific screens, the data that can be accessed, and the fields that a user can view and modify.

j. Can track all additions or changes down to the user who made the changes; write to the database each time an addition or change is made; and maintain a history of those additions and changes, including date and time the addition or change was made.

k. Enables conflict of interest and privacy restrictions, in accordance with VA security standards.

l. Can perform security scans to identify and report security vulnerabilities.

m. Ensures the encryption of data while at rest.

5.4.2.16 DATA EXCHANGE SERVICES, ELECTRONIC DATA INTERCHANGE, AND CAQH CORE

a. Can be configured to meet the security, privacy, and confidentiality requirements set forth by VA, the Health Insurance Portability and Accountability Act (HIPAA), the Affordable Healthcare Act, and the Council for Affordable Quality Healthcare, Committee on Operating Rules for Information Exchange (CAQH CORE).

b. Can receive, process, and produce HIPAA compliant transactions, including Accredited Standards Committee (ASC) X12, via EDI.

c. Can provide to the VA’s EDI system an outbound HIPAA compliant transaction that will go to other sources including internal and external trading partners or systems.

d. Remains current with on-going healthcare; electronic transactions; information exchange regulations; national format/standards; and versions of national standards including HIPAA; the Affordable Healthcare Act; and the CAQH CORE.

e. Can be configured to integrate with existing FSC systems including data translation tools and/or applications utilizing Web Services within a SOA and support data format standards such as X12 and HL7.

f. Can perform data lookups and receive data from FSC systems, perform business rules against the data, and populate and/or make selections within the configurable software, based on performing these business rules.

g. Complies with the CAQH CORE Rules which govern the way data is electronically transferred from one computer to another.

h. Integrates with external eligibility, and referral and authorization systems, following the CAQH CORE Rules.

i. Can be configured to enable the following CAQH CORE Rules and includes updates to the rules as part of the regularly scheduled maintenance of the product.

270: Connectivity Rule 370: EFT & ERA Re-association (CCD+/835) Rule 380: EFT Enrollment Data Rule 382: ERA Enrollment Data Rule 450: Health Care Claim (837) Infrastructure Rule v4.0.0 470: Connectivity Rule v4.0.0

j. Converts received claims data into readable format, rather than just lines of code.

5.4.2.17 CAPACITY AND SCALABILITY

a. Be capable of a capacity of 30 million claims annually. Claim volumes across lines of business may increase incrementally over the life of the contract.

b. Allow up to 5,000 active concurrent users, who may not be performing the same functions, on the software at the same time.

c. Be capable of processing up to 125,000 claims per day without performance degradation.

d. Allow response times on the user interface of no more than three seconds, regardless of the function being performed. Support adding IT infrastructure to scale up or scale out.

e. Be capable of configuration to provide measurable throughput on end-to-end transaction processing, of less than three seconds.

5.4.2.18 FLEXIBILITY

a. Architecture of the software provides safeguards for sensitive data within the VA Firewall: so patient and healthcare information confidentiality is maintained, and there is compliance within the regulatory environment, personally identifiable information (PII), Protected Health Information (PHI), and 38 U.S. Code §7332 Protected Data.

b. Supports Lightweight Directory Access Protocol (LDAP) integration for user access and authentication.

c. Supports single sign-on.

d. All system components shall be considered FISMA-High and shall comply with the following policies, handbooks, guidelines at the application and database levels:

i. VA Handbook 6500 (Information Security Program) www.va.gov/vapubs/viewPublication.asp?Pub_ID=56

ii. VHA Directive1906 (Data Quality Requirements for Healthcare Identity Management and Master Veteran Index) www.va.gov/vhapublications/ViewPublication.asp?pub_ID=2880

iii. NIST 800-53 Version 4 (Security and Privacy Controls for Federal Information Systems and Organizations) www.csrc.nist.gov/publications/drafts/800-53-rev4/sp800-53-rev4-ipd.pdf

iv. DISA-STIG (Defense Information Systems Agency Security Technical Implementation Guide) www.iase.disa.mil/stigs

v. OMB M-04-04 (E-Authentication Guidance for Federal Agencies) www.whitehouse.gov/sites/default/files/omb/memoranda/fy04/m04-04.pdf

vi. NIST 800-63-2 (Electronic Authentication Guideline) www.csrc.nist.gov/publications/drafts/800-63-2/sp800_63_2_draft.pdf

vii. VA Handbook 0735-HSPD-12 (Homeland Security Presidential Directive 12 Handbook) www.va.gov/vapubs/viewPublication.asp?Pub_ID=758&FType=2

a. The Contractor shall identify the testing methods and tools used to verify compliance with the above security policies, handbooks, and guidelines.

b. The Contractor shall provide proof of compliance with all security policies, handbooks, and guidelines included in this document.

Deliverables:

A. Identification of Testing Methods and Tools used to Verify Compliance B. Proof of Security Compliance

5.4.2.19 LEVEL OF AUTOMATION

With…