On November 17, 1997, the Health Care Financing Administration (HCFA) issued a memorandum to all Medicare contractors regarding compliance with Year 2000 (Y2K) issues. The memorandum is significant in that it requires all intermediaries and carriers to design systems that will exceed the current Y2K requirements in the Federal Acquisition Regulations (FAR). Because of the impact this memorandum may have on businesses and the potential ramifications for failing to comply with the HCFA memorandum, it is important that the new requirements be carefully reviewed.
HCFA has been analyzing the Y2K issue for some time, and the recent memorandum is its first step in requiring contractors to institute Y2K compliance in HCFA-related systems. The memorandum is explicit in detailing the steps HCFA intends to follow and impose upon contractors. Keep in mind, however, that the memorandum is not a regulation and does not have the force and effect of law. The principles outlined in the memorandum, however, are expected to guide HCFA’s proposed implementation of its Y2K policy.
The steps outlined in the memorandum require HCFA contractors to perform tasks and subject themselves to third-party scrutiny. Keep in mind that these tasks may not be required in existing HCFA contracts. As a result, HCFA most likely will issue contract modifications to incorporate the principles and actions detailed in the memorandum. Because the steps described below and the other actions described in the memorandum may be outside original contract requirements, HCFA’s insistence that a plan be prepared and outside testing of systems be allowed may be compensable under the changes clause of existing contracts. In any event, HCFA contractors should review their contracts to determine: (a) whether continued operations into the next century are already required by the contract; and (b) whether the actions described below are outside the original requirements of the contract.
Step 1: Issuance of HCFA guidelines for Y2K
HCFA is in the process of developing guidelines that must be used by contractors to develop the implementation plans discussed in Step 2. These guidelines will detail the minimum testing requirements to be used by HCFA to determine a system’s compliance with Y2K standards. The memorandum does not indicate when these guidelines will be issued. HCFA also will be issuing contract modifications to all existing contracts that will require Y2K compliance by December 31, 1998.
Step 2: Contractor development of Y2K implementations
The memorandum states that the HCFA Office of Information Services will soon contact intermediary and carrier contractors to require each to develop a Y2K Implementation Plan. That Plan, which must be based upon the HCFA guidelines to be issued in Step 1, must detail "what needs to be done, the time line and resources required for accomplishing all tasks, and any additional costs which may be incurred." HCFA recognizes that the actions it plans to impose upon its contractors are compensable.
HCFA intends to require contractors with existingcontracts to create such plans although it is unlikely that such a requirement currently exists in contracts. Contracts should be reviewed carefully: If the development (and implementation) of such a Y2K Implementation Plan is not required in current contracts, a contract modification should be issued by the cognizant contracting officer.
As stated, additional requirements may be outside original contract requirements, thus entitling HCFA contractors to an increase in estimated costs as well as in fees under the Changes clause. And fixed-price contracts would also be entitled to an equitable adjustment.
Step 3: Independent verification and validation
HCFA has retained an outside contractor that will provide "independent verification and validation of each contractor’s plans, processes and products necessary to bring systems into compliance." The identity of this contractor has not been provided, and it is not clear what actual or potential conflicts of interest this contractor may have with existing or future HCFA contractors. Moreover, HCFA has not yet published what standards or procedures the "independent" contractor will employ and what, if any, rights a HCFA contractor might have if it disagrees with or challenges the "independent" contractor’s assessment.
As in Step 2, current HCFA contracts most likely do not require adherence to any requirements imposed by any "independent" contractor regarding verification and validation of Y2K Implementation Plans. In other words, the contract modification that must be executed requiring the development of the Plan also should detail the identity of the "independent" validation and verification contractor, the standards that contractor will use to assess your system, appropriate statements and representations regarding limiting the use of any confidential or proprietary data the "independent" contractor may gain access to, and your rights in the event you wish to challenge the contractor’s assessment. The modification should also allow the right to reject any "independent" contractor with which there may be a conflict of interest.
Step 4: Independent testing to certify compliance
HCFA has retained another contractor that "will provide independent testing to certify that the systems are compliant." As in Step 3, the identity of the testing contractor and its state of independence has not been provided by HCFA and should be closely scrutinized by HCFA contractors.
This testing by a third party is perhaps more troublesome than the Step 3 verification and validation of the contractor’s plan. No test can assure 100 percent compliance without any faults or errors--all software contains some error. If the standard to be applied by the testing contractor is 100 percent compliance with no margin of error, it is unlikely that any system will become certified.
Moreover, the issue of certification is an interesting one that might be used to the HCFA contractor’s advantage. In military procurements, a doctrine has been established that immunizes government contractors from third-party liability if the contractor has built the weapon or part in accordance with precise design specifications. This doctrine, called the "government contractor defense," is premised on the notion that a contractor should not be held liable if it merely performs in accordance with the government’s accepted specifications.
Similarly, a contractor may not be held liable for delivering a product that conforms to a government-approved or provided design specification but does not perform as the government expected. Here, if a "certified" system subsequently fails due to the "Y2K bug," a HCFA contractor may be able to argue that the certification issued by the HCFA testing contractor, an agent of HCFA, immunizes the HCFA contractor from subsequent third-party liability. The courts have yet to apply the "government contractor defense" in the Y2K context.
Finally, the contract modification that requires the creation of the Y2K Implementation Plan and allows for the verification, validation and testing of the system, must clearly spell out how the system will be tested--where, when, by whom, under what conditions--and what pass/fail standards will be applied. Also, any requirements to assure the protection of proprietary or confidential information and the ability to appeal or challenge the testing contractor’s actions or decisions should be included in the contract modification.
Inconsistency with the FAR
In requiring all of Medicare contractors to assure that systems are Y2K compliant, HCFA’s definition of Y2K compliance is substantively inconsistent with the recently issued, final FAR (Federal Acquisition Regulations) rule definition of Y2K compliance.
An interim FAR rule inappropriately placed the burden of determining the Y2K compliance of an agency’s existing information technology (IT) systems on the contractor, and not on the government agency. This interim rule engendered a great deal of criticism and comment from industry leaders who had just concluded negotiating the Y2K GSA Warranty clause that clearly places the responsibility for determining the Y2K compliance of existing IT systems where it belongs--with the agency.
The final FAR rule contains modified language consistent with the GSA Warranty clause, which, in essence, corrected this error--contractors are no longer required to ascertain the status of an agency’s IT systems.
Instead of using the final FAR definition, however, the HCFA memorandum utilizes the verbatim definition contained in the now-abandoned interimFAR rule; thus placing the burden of determining the Y2K status of HCFA’s existing IT systems on the contractor. This is unacceptable and contractors should resist HCFA’s attempts to utilize the definition. Rather, contractors should insist that the definition used in the finalFAR rule be used.
In addition, the HCFA memorandum suggests that a contractor’s system will be required to interoperate with all systems regardless of other systems’ Y2K status. The definition supplied by HCFA for Y2K compliance requires contractors to supply systems that will accurately process date/time data received from other systems to the extent the other system properly exchanges date/time data with the new system. This portion of the definition is consistent with the FAR. HCFA, however, confuses the issue in the details it provides in the "Specific Year 2000 Compliance Requirements." There, in the section entitled "Interface Integrity," HCFA imposes the following requirements:
- the application will correctly interface with all date data that is imported or exported;
- all contractors, systems, and interfaces to HCFA (both internal and external) should be able to process data containing two and four position year data formats with no interruptions to, or failures in, processing (emphasis added).
These sections imply that a contractor’s system must correctly handle all date data whether or not that data is Y2K compliant. Perhaps, HCFA does not intend this result (especially since the HCFA definition provision clearly does not produce these consequences).
A full year early
Finally, the HCFA memorandum suggests that all intermediaries and carriers must make all Medicare-related applications Y2K compliant by December 31, 1998. This is a full year earlier than the absolute deadline for Y2K compliance imposed by the FAR, December 31, 1999. (See FAR 39.106. The FAR does allow agencies to require earlier implementation). Also, unlike the FAR, there appear to be no exceptions to this blanket requirement for Y2K compliance. The FAR Council understood that some applications either may not process date/time data or may not need to be made Y2K compliant. The HCFA memorandum does not draw such distinctions: All applications must be made Y2K compliant.
Penalties for noncompliance
The Y2K issue, in general, is indeed a serious issue with potential catastrophic consequences for systems (and businesses) that are not compliant. HCFA has made it clear that it takes this issue seriously and will impose severe sanctions on those contractors who do not comply. The HCFA memorandum states:
"Failure on the part of a contractor to bring its system into compliance will be considered a serious deficiency in contract performance. Successful completion of millennium compliance will be a strong determination in awarding other lines of Medicare business in the future. This would include, but not be limited to, receiving managed care contracts, Medicare Integrity Program contracts, or additional intermediary and carrier responsibilities. Failure by a contractor to bring its system into year 2000 compliance, as defined by HCFA, by December 31, 1998, may be grounds for denial of any new contracts or additional work under the Medicare program, or discontinuation of current contracts."
Given these consequences, it is important for each Medicare contractor to give serious attention to the requirements suggested by the HCFA memorandum and to be sensitive to the impending HCFA Guidelines and any contract modifications to be issued by HCFA. As of now, HCFA’s approach goes beyond what is required by the FAR and imposes some potentially unrealistic goals and requirements. It is important that contractors carefully review any language HCFA attempts to impose upon contracts.
Jacob B. Pankowski, a partner in the Washington, D.C., office of the law firm McKenna & Cuneo LLP, practices in the government contracts area and is chair of the firm’s Year 2000 Taskforce. For a copy of the HCFA memorandum, contact him at (200) 496-7783.
