AGENCY:
Department of Veterans Affairs.
Action:
Notice.
SUMMARY:
To encourage development of systems that help Veterans schedule appointments to receive care from the Veterans Health Administration and to reduce risks in the future procurement and deployment of those systems, the Secretary of Veterans Affairs (VA) announces a prize contest under Section 105 of the America COMPETES Reauthorization Act of 2011, Public Law 111-358 (2011), 15 USC 3719 (the “Act”).
DATES:
Entries will be accepted until 10:59 p.m. EDT on March 1, 2013. Winners will be announced on or about 90 days after the entry deadline.
ADDRESSES:
The official contest Web site is http://vascheduling.challenge.gov. Contestants must register via the official contest Web site as provided in Section 4 of the Rules set forth in this notice. Entries must be submitted electronically as specified in Section 5 of the Rules.
FOR INFORMATION CONTACT:
Michael A. Moore, Special Assistant to Chief Technology Officer, Office of the Secretary, Department of Veterans Affairs, 810 Vermont Avenue NW., Washington, DC 20420; (202) 461-5764. (This is not a toll-free number.) Also, see Section 11, below.
SUPPLEMENTARY INFORMATION:
Introduction
VA uses the Medical Scheduling Package (MSP), a component in its VistA electronic health record (EHR) system, to perform multiple interrelated functions to bring patients, clinicians and other resources together so care can be delivered. The MSP also captures data which allows VA to measure, manage and improve access to care, quality of care, operating efficiency and operating and capital resources.
VA's current MSP is more than 25 years old. It does not meet current requirements and does not provide the flexibility to support new and emerging models of care. VA will be replacing the MSP.
Using the authority of the Act and this contest, VA will obtain information that will allow it to understand various risks and thus reduce risks inherent in the procurement and deployment of highly complex mission critical software which integrates with VA's VistA system.
VA's Health Delivery System
VA's Veterans Health Administration (VHA) operates one of the largest integrated health delivery systems in the United States, delivering comprehensive care to approximately six million Veterans through a network of health care facilities owned and staffed by VA, academic medical affiliates and other contracted providers, contracted networks, and episodic fee-for-service purchases. Veterans scheduled approximately 80 million outpatient clinical visits—more than 300,000 each working day in FY 2011.
VA delivers care through 21 Veterans Integrated Services Networks (VISNs) which administer:
- 152 hospitals, sometimes known as VA Medical Centers or VAMCs,
- 971 outpatient clinics—most of which are extensions of a parent hospital, and
- 133 community living centers which deliver skilled nursing and extended care.
VHA sites of care are distributed across the United States and Puerto Rico with additional clinics in Guam and the Philippines. Veterans are administratively aligned with the hospital of their choice but may receive care through any hospital.
VA's care delivery model is centered in the Patient Aligned Care Team (PACT), VA's implementation of the Patient Centered Medical Home.
- PACTs consist of multidisciplinary clinical and support staff that deliver all primary care and coordinate the remainder of patients' needs, including specialty care.
- Veterans assigned to a PACT may schedule appointments with any member of the team.
- Routine appointments with specialists are often scheduled based on a PACT referral; specialty care referrals can also come from clinicians providing inpatient care, the Emergency Department, community providers, or patients themselves.
- Veterans generally schedule their own follow-up appointments with specialists or specialty care services without the intervention of the PACT.
Appointment scheduling is currently performed primarily via telephone, in person, or mail. The intervention of a VA employee is currently required to make appointments. VA needs to enable Veterans to schedule their own appointments electronically via online and mobile devices.
VA also needs to schedule and coordinate care across internal and external administrative, or system, boundaries. As examples:
- Veterans may choose to live in different states at different times of the year and need to make appointments to receive care where they live when they need it.
- A clinician who can provide needed care for a Veteran may be located at a different hospital, in different VISN or at an external academic affiliate or contract medical group.
- A physician who will be examining a Veteran to determine nature and extent of a service-related disability may also be located at a different hospital, VISN, or be delivering examination services under contract.
- Telemedicine technologies can support care delivery by a clinician who is physically located at a different hospital or even in a different VISN than the physical location where the Veteran will receive the care.
- PACTS need to coordinate care with non-VA community providers when Veterans choose to receive care both inside and outside the VA system.
- Support services such as non-VA transportation services must be coordinated.
VA currently relies on the MSP to perform non-scheduling functions including workload data capture and a broad range of workload and other management reports.
VA's Technical Infrastructure
VA's current medical MSP is a component (application) of its VistA electronic health record (EHR) system.
The MSP is tightly integrated with VistA; it reads data from more than 130 other VistA applications and has read/write functionality with more than 30 additional applications.
VistA systems are localized at the hospital level and will remain so for at least the near-term future. Each hospital operates a separate instance of VistA. Portions of the VistA code are identical in each instance; different instances of VistA may have different interfaces between the MSP and other VistA applications.
Any replacement product must not negatively impact any current applications that interface with the MSP or its data.
Replacing VA's Medical Scheduling Software
VA intends to replace the current MSP with a scheduling product which is a standards-based, modular, extensible and scalable, certified as compliant and fully interoperable with the production version of VistA now held by the Open Source Electronic Health Record Agent (OSEHRA), http://www.osehra.org/.
As used in this notice, “product” means either a discrete software module which is installed on VA servers or a software service.
The replacement product must effectively perform VA's scheduling-centric and scheduling-related legacy business functions. It must also demonstrate it can meet non-functional requirements including integration with multiple instances of VistA.
The replacement product will, as a part of the overall VistA EHR, deliver privacy, security, data integrity, patient accessibility, interoperability and other services required by federal law, regulations and VA policy. Many of these services are delivered by other components of VistA.
Role of This Contest in Replacement of VA's Medical Scheduling Software
This contest will achieve two significant goals in replacement of VA's MSP.
- First, it will mitigate risks which VA has identified as contributing to the failure of previous attempts to replace the MSP.
- Second, it will encourage commercial software vendors to actively engage in development of solutions, by providing a basis on which VA can rate proposals in any subsequent procurement of a replacement for the MSP.
Risk Mitigation. VA's previous attempts to replace the MSP module in VistA were not successful. Assessments of the reasons for these failures identified three critical risks that VA will mitigate via this contest:
- Market Research: One of the reasons VA was not successful was lack of sufficient knowledge about the actual capabilities of vendors to meet VA's business needs. Via this contest, VA will obtain valuable information about industry's current ability to meet VA's business needs via actual demonstration of product capabilities in a VA-defined test environment. Additionally, VA will be able to assess industry's ability to perform not just scheduling-centric functions offered by most robust scheduling products, but also scheduling-related workload-capture and data-reporting functions that are unique to VA. This contest will also provide VA with valuable information about changes in business workflows that will be needed when a replacement product is deployed.
- Integration issues: Another reason why earlier attempts were not successful was VA's inability to effectively integrate replacement software with the VistA system. Since then, VA has elected to place VistA in the open source community and to prefer software products which are openly architected to integrate with VistA. Via this contest, VA will be able to assess industry's ability to technically integrate its products with Open Source VistA.
- Test environment: Analyses for the previous lack of success also found that VA was unable to effectively test replacement software to assure it met functional and technical requirements. To support this contest VA will develop and deploy a test environment, judge contest entries using that test environment, assess the effectiveness of the test environment, then use the results of that assessment to adjust the test environment as needed to support testing in a procurement of a deployable scheduling replacement product.
Via this contest, VA will obtain the needed information in a lower-risk-of-failure context than if directly procuring a deployable replacement product. VA believes the information it obtains via direct evaluation of entries in this contest will be superior in quality and can be obtained in significantly less time via this contest route than by custom development. VA also believes the aggregate cost of the contest is highly competitive with the cost of acquiring the same types of information via other arrangements. If industry is not able to demonstrate it can meet VA's needs then no prize will be awarded.
Effect on Subsequent Procurement. VA anticipates that compatibility with Open Source VistA will be among the requirements in any subsequent procurement of a replacement for the MSP. Demonstration of open source compatibility in this contest may be taken into consideration in the rating of proposals in any subsequent procurement.
Contest Requirements and Rules
1. Subject of the Contest. The goal of this contest is to encourage creation of systems that help Veterans make appointments to receive outpatient and ambulatory care from the Veterans Health Administration. VA also seeks to obtain information which will allow it to reduce the risks inherent in procurement and deployment of a replacement medical scheduling product.
Scheduling of inpatient, surgical, and extended nursing care is excluded.
2. Numbers and Amounts of Prizes.
a. VA will award monetary prizes of as much as $3 Million to as many as three entrants that deliver demonstration software or service which the judges determine delivers the required functionality and is compatible with Open Source VistA, as described in this notice.
b. Judges will determine the number and amount of monetary prizes. Judges may determine that no prize will be awarded.
c. VA may consider compatibility with Open Source VistA as demonstrated in this contest when considering proposals in any subsequent procurement of MSP-related product(s).
3. Basis on which a winner will be selected. (See section 6 for judging procedures and point system.) Winners will be selected from entries that demonstrate to the satisfaction of the judges that they:
Winning products will be used for demonstration only and will not be deployed in VA facilities except for testing or demonstration purposes.
a. Perform as required by these rules while interfaced with VA-provided VistA instances running on VA-provided virtual machines. Performance with other versions or instances of VistA will not be considered.
b. Perform each of the scheduling-centric business functions defined by VA on Attachment A to this notice, including particularly:
1. Automated scheduling of an appointment at any VA site from any location by a Veteran using online or mobile devices or by a VA employee acting as a scheduler, and
See, e.g., Attachment A, sections 1.4.1, 1.4.5, 2.7, 3
2. Where semi-automated scheduling is performed, use of a calendar-view format presentation of available resource(s), with support for point-and-click scheduling when the calendar view shows needed resources to be available.
See, e.g., Attachment A, sections 1.2.5, 3, 3.5, 3.7.
c. Perform all or some of the designated Scheduling-Related/VA-Specific business functions set forth on Attachment B to this notice, including functions related to workload capture, data analysis and reporting, operational and capital planning and travel reimbursement.
d. Perform each of the non-functional requirements set forth on Attachment C to this notice.
e. Do so using open APIs, including open source code for the interfaces between the product and VistA, and at the option of the entrant, using open source modules to support some or all of the product's additional functions. Note: Entries that consist of proprietary code are not precluded, so long as interfaces with VistA use open APIs and the software implementing the interfaces is made available as open source code.
4. Registration for this Contest.
a. Not later than 10:59 p.m. EST February 1, 2013, potential entrants must request registration for the contest by submitting a letter via the “Submissions” section of the official contest Web site, http://vascheduling.challenge.gov. The letter must be signed by the entrant if an individual or by a corporate officer if the entrant is a corporation. The letter must:
1. Attest that the potential entrant is eligible to participate in this contest per the requirements of this notice and the Act,
2. Attest that disqualifying factors for participation in the contest, as defined in this notice and the Act, do not exist,
3. Contain a listing (which may be an attachment) of all owners of all intellectual property (IP) which the potential entrant will incorporate or use in its entry,
4. Contain a listing (which may be an attachment) of all components of the entry that the potential entrant will designate as open source,
5. Attest that the potential entrant is the owner or licensee of any and all intellectual property (IP) to be incorporated in the entry, and by virtue of such ownership or license has full right and authority to authorize, and does authorize VA (and any of VA's consultants, contractors or collaborating federal agencies) to reproduce, test, demonstrate and use such IP for any purpose related to this contest, including judging,
6. Attest that the potential entrant:
a. Is the owner or licensee of any and all IP in open source modules designated by the entrant to be incorporated in the entry;
b. Has full right and authority to convey all rights set forth in an Apache 2.0 license in the designated open source modules; and
Text available at http://www.apache.org/licenses/LICENSE-2.0.
c. Will, if selected as a winner in this contest, apply the Apache 2.0 license to the designated source modules and contribute the software to OSEHRA.
7. Attest that the potential entrant agrees it is bound by all rules, assumes all risks, and has acquired or will acquire any insurance required by this notice.
8. State whether the potential entry will be an installable software, software as a service (SaaS) or contain components of both, and whether the contestant intends to supply resources external to the virtual machines to be provided by VA to support or execute the contestant's entry (e.g., servers that support SaaS), and identifying those resources.
9. State the name, business and email address and telephone number of the individual who is the designated contact for and who will receive all communications related to this contest.
a. The letter, attachments, and any additional written materials must be submitted electronically in a format fully compatible with both Microsoft Word 2007 and Adobe Acrobat Pro 9.
b. Letters which do not include each of the items stated in paragraph 4(a) and in the required formats will not be effective to register the potential entrant.
c. At the option of the potential entrant, letters may be accompanied by additional written materials describing the potential entrant or the entry not exceeding ten 81/2 by 11 inch pages in length. These materials will be in a format fully compatible with Microsoft Word 2007 or Adobe Acrobat Pro 9.
d. Letters and all attachments are subject to file size limits of the official contest Web site.
5. Procedures for Submitting Entries; Confidentiality of Entries.
a. Potential entrants that submit a letter meeting the requirements set forth in Section 4, above, will be registered for this contest.
1. Registered contestants will be sent an email at the address provided by the contestant. The email will contain instructions on how to access VA-supplied virtual machine space to integrate, configure, and test their solution prior to submission as an entry.
2. Depending on the number of potential entrants that register for this contest and the ready availability of virtual machines, there may be a delay between submission of a letter requesting registration and an email accepting the letter. There may also be delay in actual availability of virtual machines. Potential entrants assume all risk of such delays and the possibility that any delay may leave them insufficient time before the entry deadline to fully integrate, configure and test their solution.
b. Each contestant will be supplied with three virtual machines.
1. Each machine will be loaded with a sample instance of VistA with sample data, each with a different patch level and each set to operate in a different time zone. This will permit configuration and testing of multiple-site scheduling functions.
2. Two of the virtual machines will use the Red Hat Enterprise Linux 6.1 (64 bit) operating system. The third machine will use the Windows Server 2008 (32 bit) operating system.
3. Contestants may begin installation and testing of their product immediately upon receipt of access to the virtual space.
c. Contestants may provide resources in addition to the virtual machines provided by VA, e.g., servers which support SaaS.
1. Integration of all external resources with the virtual machines provided by VA will be the sole responsibility of the contestant.
2. All expenses related to any additional resources will be at the sole cost and expense of the contestant.
d. VA will post Screening Use Cases in the “Updates” section on the contest Web site, http://vascheduling.challenge.gov. These Use Cases will be used in the evaluation of the functional and technical capabilities of entries.
e. Each contestant will integrate their solution with the provided VistA instances, and will provide test plans and automated test scripts that demonstrate performance of the functional requirements on Attachments A, B, and C in the context of the Screening Use Cases.
f. Test scripts must meet the following requirements:
1. Scripts must be submitted as open source software, in accordance with the criteria posted on the contest Web site, including documentation and OSI-approved open source licenses, with the Apache 2.0 license applied to all code. The submittal must include instructions for execution and a copy of results for comparison.
2. Scripts must operate in the OSEHRA CTEST environment.
3. Scripts must be repeatable, that is, they must include separated executable automated code that restores all data values to their previous state, allowing the test to be rerun with consistent results.
4. If any changes are made to the provided VistA instances, those changes must also be submitted as open source code, compliant with the criteria posted on the contest Web site including documentation and OSI-approved open source licenses, with the Apache 2.0 license applied to all code. This includes the VistA-side components of any interface code, such as Applications Program Interfaces (APIs).
5. Contestant must submit repeatable open source test scripts for all specified use cases in accordance with the instructions posted on the contest Web site, with instructions and results from their testing.
g. Each registered contestant that wishes its or their product to be formally entered in the contest shall, not later than 10:59 p.m. EST March 1, 2013, submit a letter via the “Submissions” section of the official contest Web site, http://vascheduling.challenge.gov. The letter must be signed by the entrant if an individual or by a corporate officer if the entrant is a corporation. The letter must state:
1. The registered contestant has completed installation of its or their product, test plans and automated test scripts on the virtual servers provided by VA, has completed testing to its or their satisfaction, and formally submits the contents of the virtual machines as their entry in the contest.
2. The letter submitted by the registered contestant at the time of registration is incorporated by reference and the contents of that letter are in all respects ratified and confirmed. Provided, however, that contestants may at their option amend the contents of the following sections of the registration letter:
a. Section 4(a)(3), relating to a listing of the owners of all IP incorporated into the contestant's entry;
b. Section 4(a)(4), relating to the components of the entry which the contestant will designate as open source;
c. Section 4(a)(8), relating to whether the entry is installable software, SaaS, or contains components of both and whether resources external to the VA-supplied virtual machines is or will be used by the contestant to support or execute contestant's entry.
d. Section 4(a)(9), relating to contact information.
e. Section 4(d), relating to optional descriptive materials.
3. If resources external to the VA-supplied virtual machines is or will be used by a contestant to support or execute contestant's entry, the letter shall also state: “[I/We] certify that from and after the submission of this letter until the announcement of the contest winners, no changes whatsoever will be made to any of the external software or resources [I/we] have designated to support or execute [my/our] entry.”
4. Registered contestants that do not submit a letter as required by this subsection will be deemed to have withdrawn from the contest and the contents of virtual machines assigned to them will not be judged.
5. Letters formally submitting entries for judging, along with all attachments, are subject to file size limits of the official contest Web site.
h. All virtual machine environments will be frozen as of 10:59 p.m. EST March 1, 2013. If a registered contestant has submitted a letter as provided in section 5(g), then the contestant's entry in this contest will be deemed to be the code and other content installed on the virtual machines at the time the virtual machine environment is frozen, as well as the code and other contest installed on external resources if any, at that time.
i. Submissions or entries will not be readily available to other entrants or to the public. These materials may, however, be disclosable as determined solely by VA pursuant to its obligation to comply with the Freedom of Information Act (FOIA), 5 U.S.C. 552.
6. Judging of Entries.
a. Method. VA may use any technical means it determines suitable to evaluate any entry, award points and determine any winner in this contest. All or any part of the evaluation may be conducted by third parties under VA supervision. VA may use an entrant's submitted testing scripts, routines and software to perform all or part of any evaluation and judging. VA may, at its option, request an entrant to demonstrate its or their entry either in-person or via web-based technologies.
b. Technical Evaluation. VA contemplates it will judge entries as follows.
1. An entry will first be evaluated to determine Open Source VistA Compatibility, i.e.:
a. Whether it is compatible with the three separate VistA instances on the VA-supplied virtual machines, and
b. Whether the interfaces between the product and VistA are based on software code that either is or can become open source.
VA contemplates substantial portions of this evaluation will be conducted by OSEHRA. Any entry that does not demonstrate Open Source VistA Compatibility to the satisfaction of the judges will be disqualified and will not be further considered for a prize.
2. An entry which demonstrates Open Source VistA Compatibility will then be evaluated to determine whether it performs all Non-Functional requirements set forth on Attachment C. Any entry which does not demonstrate to the satisfaction of the judges that it can perform the Non-Functional Requirements on Attachment C will be disqualified and will not be further considered for a prize.
3. Entries which demonstrate Open Source VistA Compatibility and also demonstrate they meet Non-functional Requirements will be deemed to be Technically Compatible.
c. Functional Evaluation. VA will evaluate an entry that has demonstrated Technical Compatibility to determine whether it can perform the Scheduling-centric functions defined on Attachment A. An entry that does not demonstrate to the satisfaction of the judges that it can perform the Scheduling-centric functions defined on Attachment A will be disqualified and will not be further considered for a prize.
d. VA-Specific Functions. An entry that demonstrates Technical Compatibility and also demonstrates it can perform all of the Scheduling-centric functions on Attachment A will then be evaluated to determine whether it can perform any of the Scheduling-related or VA-specific functions defined on Attachment B.
1. Judges will award the designated points for each function defined on Attachment B that they determine is performed by the entry.
2. A maximum of 120 points can be awarded for performance of functions defined on Attachment B.
e. Open Source Content. An entry that demonstrates Technical Compatibility and also demonstrates it can perform all of the Scheduling-centric functions on Attachment A will also be evaluated by the judges to determine the extent to which it uses software modules, as designated by the entrant, which are or will become open source.
1. Interfaces between the product and VistA will not be considered in this phase of the judging, as they are a required component of Open Source Compatibility.
2. Judges will evaluate the significance of the designated open source modules in delivering required functions. For example, judges may determine that modules that provide common platform services or business logic are more significant than modules that deliver the presentation layer.
3. Judges may award a maximum of 30 points for significant open source modules incorporated in an entry.
Points awarded by the judges will determine the winners of this contest.
7. Eligibility. To be eligible to participate in this contest and win a prize:
a. Entrants must register for this contest as set forth in Section 4 and submit a letter formally entering their product in the contest as set forth in Section 5.
b. If an individual, an entrant must be a citizen of or permanent resident of the United States. If an entity, an entrant must be incorporated in and maintain a primary place of business in the United States.
c. An entrant may not be a Federal entity or Federal employee acting in the scope of the employee's employment.
d. Entrants shall be responsible for obtaining insurance they deem necessary to cover claims by any third party for death, bodily injury, or property damage or loss resulting from an activity carried out in connection with or participation in this contest.
e. Entrants must have complied with all requirements of this notice and all requirements established by the Act.
f. By registering for or submitting an entry in this contest, contestants and entrants agree to assume any and all risks and waive any claims against the Federal Government and its related entities (except in the case of willful misconduct) for any injury, death, damage, or loss of property, revenue or profits, whether direct, indirect, or consequential, arising from their participation in this contest, whether the injury, death, damage, or loss arises through negligence of otherwise. Provided, however, that by registering or submitting an entry, contestants and entrants do not waive claims against VA arising out of the unauthorized use or disclosure by the agency of the intellectual property, trade secrets, or confidential information of the entrant.
8. Intellectual Property (IP).
a. VA is not responsible for a registered contestant's or entrant's lack of compliance with copyright, trademark, patent or other Federal law. Contestants and entrants will hold harmless, defend, and indemnify the Federal Government and any agency or component thereof from and against any suit, claim, demand, liability, damages, costs and expenses (including attorneys' fees and costs of defense), of whatever nature, whether groundless, false or fraudulent, arising out of any use, licensing or relicensing of any IP that is incorporated in the entrant's entry.
b. Without limiting the generality of the foregoing and in explanation but not limitation of sections 4(a)(5) and 4(a)(6), contestants and entrants are responsible for obtaining all third-party licenses required to allow the VA and its contractors to receive any and all IP installed on any virtual machine, to run any and all testing software or scripts, and to demonstrate an entrant's product. Windows and Linux operating systems will be accepted; however contestants and entrants will need to obtain proper licenses for running any Windows in any resource external to the VA-supplied virtual machines that is or will be used by the contestant to support or execute contestant's entry.
c. The winner(s) of this contest will, in consideration of the prize to be awarded, apply the Apache 2.0 license to the designated open source modules (including the interfaces between winner's product and VistA) and contribute the modules to OSEHRA.
d. VA may in its sole and absolute discretion choose to negotiate with any entrant to acquire, license, use or convey any other intellectual property developed in connection with this contest.
9. Judges and Judging Procedures.
a. Subject to the requirements of 15 U.S.C. 3719(k), the VA Assistant Secretary for Information Technology, acting on behalf and with the authority of the Secretary of VA, will appoint one or more qualified individuals to act as judges of this contest and may appoint himself as a judge. Judges may include individuals from outside VA, including from the private sector. Judges will operate in a transparent manner.
b. A judge may not have a personal or financial interest in, or be an employee, officer, director, or agent of any entity that is a registered entrant in this contest, and may not have a familial or financial relationship with an individual who is a registered entrant.
c. Specific tasks related to the judging process may be delegated to VA employees or employees of a collaborating Federal agency. Third parties may perform judging tasks subject to supervision by VA or by a collaborating Federal agency.
d. Judges shall have the authority to disregard any minor error in any entry that does not create any substantial benefit or detriment to any entrant.
e. Judges shall have the authority to obtain from any entrant additional information, clarification of information, or assistance in resolving any technical issues relating to the installation, use, testing or evaluation of any entry, so long as no substantial benefit or detriment to any entrant occurs thereby.
f. Decisions of the judges are final.
10. Payment of Prizes.
a. Prior to payment of any prize, an apparent winner must execute (at VA's option, under oath or affirmation) such documents as VA may reasonably require, including but not limited to:
1. Declarations and certifications that relate to the apparent winner's eligibility to participate in this contest, the absence of any disqualifying factor, the assumption of risks and acquisition of any insurance required by the rules,
2. The conveyance of any intellectual property required by the rules, and
3. Any other matter that VA may reasonably require, including but not limited to information reasonably necessary for VA to make payment via electronic funds transfer and issue IRS Forms 1099 according to VA's fiscal policy.
11. Procedures for obtaining additional information.
a. During the period of the contest, potential contestants or entrants may submit questions or comments to VA using the “Discussions” section on the official contest Web site, http://vascheduling.challenge.gov.
b. VA may choose not to respond to any question or comment or to delete questions or comments that it determines are not relevant to the competition or which seek technical guidance. VA's responses on the “Discussion” section of the contest Web site are not official guidance.
c. VA may also provide information and official guidance related to this contest on the “Updates” section of the official contest Web site, http://vascheduling.challenge.gov. An entrant is bound by official guidance on the “Updates” section that is posted prior to formal submission of their entry.
Signing Authority
The Secretary of Veterans Affairs, or designee, approved this document and authorized the undersigned to sign and submit the document to the Office of the Federal Register for publication electronically as an official document of the Department of Veterans Affairs. John R. Gingrich, Chief of Staff, Department of Veterans Affairs, approved this document on October 11, 2012, for publication.
Dated: October 11, 2012.
Robert C. McFetridge,
Director, Regulation Policy and Management, Office of the General Counsel, Department of Veterans Affairs.
Attachment A—Scheduling—Centric Functional Requirements
Business need (BN) | Revised owner No. | Owner requirement (OWNR) |
---|---|---|
BN 1: Manage National Medical Scheduling Setup—The scheduling system shall provide the capability to configure and manage business rules and standards at a national level including establishing parameters for role-based user access and security and supporting a process to monitor and evaluate results of audit reports. | 1.1 | The system shall have the capability to provide integrated, electronic access to and from other VistA applications. |
1.2 | Maintain and Modify Scheduling Configuration—The system shall provide the capability to establish and maintain national, VISN, VAMC, clinic, provider-level configuration standards. Configuration shall be enabled for facility-level within business rules and parameters. | |
1.2.1 | The system shall have the capability to provide on-line help. | |
1.2.2 | The system shall have the capability to maintain an audit trail of changes to resource configuration. | |
1.2.3 | The system shall have the capability to create, modify, and delete configurable business rules that are used in the scheduling process. | |
1.2.4 | The system shall provide the capability to configure resources at the National, VISN, facility, clinic and provider levels. | |
1.2.5 | The system shall provide synchronization with individual (patient or provider) Office Automation calendar for multiple types of end user devices, including mobile applications irrespective of operating system. | |
1.3 | Flexible Appointment Scheduling—The scheduling system shall provide the capability to configure schedule parameters. | |
1.3.1 | The system shall allow configuration of scheduling to accommodate holidays. | |
1.3.2 | The system shall allow flexible schedule options for urgent care and walk-in appointments. | |
1.3.3 | The system shall allow scheduling between facilities located in different time zones. | |
1.3.4 | The system shall have the capability to allow users to specify timing relationships between activities (e.g., coordinate multiple activities in specified order). | |
1.3.5 | The system shall be configurable to display only available resources. | |
1.3.6 | The system shall have the capability to allow users to define a standard set of appointment types with default appointment lengths. | |
1.3.7 | The system shall have the capability to search for available appointments using specific parameters and to display results for multiple resources in a single view. | |
1.4 | User Access—The system shall provide the ability to maintain and modify user access. | |
1.4.1 | The system shall provide role-based security for access control and provide improved remote access for Veterans to make and view appointments over the internet, email and other mobile devices. | |
1.4.2 | The system shall have the ability to create, configure, and maintain role-based user (staff and veteran) access and authorization. | |
1.4.3 | The system shall allow configuration and tailoring of user access roles at the national, VISN, facility, clinic, and provider levels based on business rules and policies. | |
1.4.4 | The system shall have the capability to enforce rules concerning what roles can overbook appointments for a service or resource. | |
1.4.5 | The system shall have the capability to allow, in certain circumstances, Veterans to schedule appointments via remote access mechanisms such as phone, internet, email and other mobile devices. | |
1.5 | Resources and Groups—The system shall provide the capability to create, modify, manage, delete, and report on resources and groups. | |
1.6 | Audit Trails—The system shall have the capability to display business and technical audit trails. | |
1.6.1 | The system shall provide the ability to record data to produce audit trails for items including: user access activities, modifications to schedules. | |
1.7 | Templates—The system shall have the capability to create, modify, change status, and manage of templates which include notifications, letters, and scheduling events. The system shall allow the templates to be shared and saved. | |
1.7.1 | The system shall allow the templates to be shared. | |
1.7.2 | The system shall allow the templates to be saved. | |
1.8 | The system shall allow for the configuration of notifications, flags and alerts for scheduling process. | |
BN 2: Manage Veteran Information—The system shall have the ability to access and manage, update and maintain accurate Veteran information. Veteran special needs and preferences shall be accessible and able to be updated in “real-time”. | 2.1 | The system shall have the capability to provide alerts if patient information is missing, out of date, or requires verification (e.g., eligibility, means test, demographics). |
2.2 | The system shall have the capability to maintain and present appointment information (past and future) within a specified date range (e.g., including appointments kept, providers, cancellations and no-show history). | |
2.3 | The system shall have the capability to display eligibility information necessary for appropriate scheduling. | |
2.4 | The system shall have the ability to notify/inform schedulers of patient preferences. | |
2.5 | The system shall have the capability to receive notification of deceased patients and allow the authorized user to cancel future appointments/ancillary services/orders once notification has been received from an authoritative source. | |
2.6 | The system shall have the capability to establish and update patient information (enrollment status, eligibility, demographics, preferences and special needs, means test status, provider assignments, etc.). | |
2.7 | The system shall have the capability to allow patient appointments with multiple providers at multiple facilities. | |
2.8 | The system shall provide the ability to identify and verify the identification of the Veteran. | |
2.9 | The system shall support user configuration preferences for data display and entry screens within security and standards constraints. | |
BN 3: Manage Request—Through the use of a calendar view, the scheduler is able to view all providers, services, facilities, and Veterans from a variety of calendar views such as: daily, weekly, monthly with multiple providers, services or facilities in view on a single screen. The scheduling system shall accommodate appointment requests from multiple inputs sources, including Veterans and providers via different sources such as MyHeatheVet, walk-ins, email and other communication modes. This forms the basis of non-solicited demand. Solicited demand emerges in the form of unfulfilled appointments based on missed opportunities or requests outside the scheduling appointment horizon. | 3.1 | Variable Appointment Types and Lengths—The system shall have the capability to allow variable appointment types and variable appointment lengths [e.g., Compensation & Pension (C&P), Mental Health Clinic (MHC), Primary Care Clinic (PCC), New, Follow-up, Pre-op, Post-op]. |
3.1.1 | The scheduling system shall display any other scheduled or requested appointments for the patient when an appointment is requested. | |
3.1.2 | The system shall have the capability to allow users to schedule an appointment for a specific, user-defined, length of time, based on role-based access rules. | |
3.1.3 | The system shall have the capability to establish recurring appointments. | |
3.1.4 | The system shall provide the ability to verify patient information, display eligibility, and display a warning if there is an inconsistency between service requested and eligibility. | |
3.2 | Appointment Selection—The system shall have the capability to manage the appointment selection process. | |
3.3 | Providers Per Schedule—The system shall have the capability to coordinate appointment scheduling based on resource availability. | |
3.4 | Access Restrictions for Scheduling Appointments—The system shall have the capability to filter available appointments based on patient preferences, appointment availability, geographic considerations, facility, date range, resource type, and other special needs. | |
3.5 | Waiting Lists—The system shall provide the capability to process various lists. | |
3.5.1 | The system shall have the capability to provide a waiting list that appears when making or canceling appointments. | |
3.5.2 | The system shall apply configurable business rules to the management of a long-term appointment request list. | |
3.5.3 | The system shall have the capability to maintain a list of patients that can fill a cancelled appointment on short notice. | |
3.5.4 | The system shall have the capability to provide users the ability to view available appointments beyond one year. | |
3.5.5 | The system shall have the capability to maintain an electronic waiting list. | |
3.6 | Appointment Rescheduling—The system shall identify appointments to be rescheduled and route them automatically to the reschedule status or pending list. | |
3.6.1 | The system shall have the capability to disposition rebooking of no-shows. | |
3.6.2 | The system shall have the capability to link associated appointments so that if one is cancelled, all linked appointments can be dispositioned together. | |
3.6.3 | The system shall be capable of finding and displaying available appointment slots due to appointment cancellations, additional resources, etc. based upon configuration parameters. | |
3.6.4 | The system shall have the capability to permit automatic rebooking of patients into comparable appointment slots. | |
3.6.5 | The system shall have the capability to merge, purge, or distribute scheduled appointments from one resource to another. | |
3.7 | Optimize Resource Utilization—The system shall incorporate mechanisms that support optimization of resources. | |
3.7.1 | The system shall have the capability to capture the coded reason for cancellations/no-shows, e.g., death of patient, lack of transportation, snow day. | |
3.7.2 | The system shall have the capability to book or cancel recurring appointments (e.g., recurring appointments to same resource) all at once. | |
3.7.3 | The system shall have the capability to provide users the capability to view available appointments based on configuration parameters. | |
3.7.4 | The system shall have the capability to receive notification of expired/deceased patients from authoritative source and take appropriate action such as cancel future appointments/ancillary services/orders, etc. | |
3.7.5 | The system shall have the capability to detect and notify users if patients have similar appointments (service; provider) scheduled close together (e.g., possible duplicate or both can be seen at one time). | |
3.7.6 | The system shall check availability and status of all resources, including telecommunications system availability, for a clinical video telehealth session. | |
3.8 | Appointment Requests—The system shall have the capability to manage appointment requests. | |
3.8.1 | The system shall have the ability to place Veterans on an appointment list which is accessible throughout the scheduling process. | |
3.8.2 | The system shall have the ability to merge, purge, or distribute scheduled appointments from one resource to another when emergency scheduling changes occur. | |
3.8.3 | The system shall have the ability to capture attempts to contact patient. | |
BN 4: Manage Appointment—Through the use of a calendar view, the scheduler is able to view all providers, services, facilities, and Veterans from a variety of calendar views such as: daily, weekly, monthly with multiple providers, services or facilities in view on a single screen. | 4.1 | The system shall have the ability to display co-pay requirements. |
4.1.1 | The scheduling system will display patient special needs and preferences when an appointment is requested and made. | |
4.1.2 | The system should allow configuration to require approved authorizations prior to processing an appointment request. | |
4.1.3 | The system shall have the capability to create and manage various appointment types. | |
4.1.4 | The system shall have the capability to manage scheduling process, such as overbooking, no-shows, cancels, re-schedules, etc. | |
4.1.5 | The system shall support the ability to change or edit appointments as necessary. | |
4.1.6 | The system shall have the capability to configure and enforce business rules at the clinical service level, clinic level, provider, and appointment type level (e.g., females in Obstetrics/Gynecology clinic). | |
4.1.7 | The system shall provide the ability for providers to request appointments. | |
4.2 | Linking—The system shall have the ability to automatically link relevant appointments/resources. | |
4.2.1 | The system shall have the capability to provide alerts when ancillary tests/specialty consults have been scheduled/missed. | |
4.2.2 | The system shall have the capability to search for the available appointment across multiple resources. | |
4.2.3 | The system shall have the capability to provide information to assist schedulers to consolidate appointments in one day when possible (e.g., flag the fact that a patient is scheduled to show up +X days of desired new appointment date). | |
4.2.4 | The system shall have the capability to create, re-schedule, or cancel recurring appointments all at once with appropriate desired date. | |
4.2.5 | The system shall have the capability to define individual schedules in terms of a single resource or as a pre-defined set of multiple resources. | |
4.2.6 | The system shall have the capability to create groups of resources for scheduling a single event (e.g., room, equipment, and ancillary staff). | |
4.2.7 | The system shall have the capability to cancel/restore resources and all linked appointments over multiple days (not just one day at a time). | |
4.3 | Assign and Configure Time Slots—The system shall provide the capacity to assign and configure time slots for appointments. | |
4.3.1 | The system shall have the capability to block time slots in user-defined increments. | |
4.3.2 | The system shall have the capability to present alerts and reminders for a variety of reasons (e.g., eligibility not verified, means test or insurance information out of date). | |
4.3.3 | The system should have the capability to support automated coordination and consolidation (e.g., onto one day) of multiple appointments per patient. | |
4.3.4 | The system shall be capable of changing appointment types for an appointment or a request at any time (within business constraints). | |
4.3.5 | The system shall have the capability to configure the amount of time allowed between appointments for a patient with multiple appointments. | |
4.3.6 | The system shall not permit booking appointments into invalid time slots based upon configured business rules. | |
4.4 | System Prompt Patient Notifications—The system will provide the ability to establish and provide appointment notifications. | |
4.4.1 | The system shall have the capability to generate a list of future appointment reminders. | |
4.4.2 | The system shall have the capability to produce appointment notifications in a variety of formats (e.g., letter, phone, e-mail, text messaging, pending appointment list, or card). Each option shall be capable of being enabled or disabled based upon patient preferences. | |
4.4.3 | The system shall have the capability to filter/select appointment notifications based on user defined criteria. | |
4.4.4 | The system shall have the capability to tailor appointment notifications to meet specific clinic needs. | |
4.4.5 | The system shall have the capability to provide configurable notification requests such as: alerting staff when to contact patients about upcoming appointments. | |
BN 5: Coordinate Associated and Occasions of Service—The scheduling system shall provide schedulers the ability to coordinate medical services throughout the VA, for other agencies, with private practices, and for various delivery modes and causes. | 5.1 | External Data Exchange—The system shall have the capability to provide secure, automated interfaces with external systems for data exchange. |
5.1.1 | The system shall have the ability to allow inter-facility scheduling, including non-VA facilities. | |
5.1.2 | The system shall have the capability to link unscheduled CPRS consults to the scheduling system for viewing. | |
5.1.3 | The system shall have the capability to support coordinating multiple appointments (e.g., provide information helpful in scheduling all appointments on one day, multidisciplinary team appointments). | |
5.2 | The system shall provide the ability to allow display of primary and associate providers designated by facilities. | |
5.2.1 | Ability to schedule a patient and resource on both the VistA system where the health care resource is located and the VistA system where the Veteran is located. This combination should be handled across VistA systems and time zones as appropriate as a synchronized event. | |
5.2.2 | The system shall provide the capability to capture and to select locations of patient and healthcare resources, including non-VA facilities (e.g., Veteran home, DoD, academic affiliate, contract provider, etc.). | |
5.2.3 | The system shall provide the ability to create, cancel and update Clinical Video Telehealth (CVT) appointment sets (patient and provider) as a single event (to prevent creation of orphans), including the following resources: | |
• CVT Rooms. | ||
• CVT Equipment. | ||
• Telepresenter. | ||
5.2.4 | The system shall provide the ability to modify a CVT appointment pair (patient and provider) as needed to prevent creation of orphans or to correct errors. | |
5.3 | Ancillary Services—The system shall have the capability to accommodate different service types such as C&P, ancillary services and specialty services. | |
5.3.1 | The system shall have the capability to link ancillary tests to appointments (if they are changed, ancillary tests can be updated without canceling order and re-ordering). | |
5.3.2 | The system shall have the capability to link ancillary tests to appointments. | |
5.3.3 | The system shall provide the capability to establish links to activities that require coordination with appointments (e.g., ancillary services). | |
5.3.4 | The system shall have the capability to coordinate appointments with related ancillary services. | |
5.4 | The system shall have the capability to provide a patient preference field that informs clerks to special transportation concerns or other issues that limit availability (e.g., specific days and times). | |
BN 6: Manage Encounter of Care—The system will have the capability to differentiate between encounter data and appointment data. The encounter data is not tracked by the scheduler, but by providers in the electronic health record. | 6.1 | The system shall have the capability to provide check-in, check-out, cancellation reasons, and no-show data. |
6.2 | The system shall have the capability to provide facility-wide visibility for a patient (i.e. checked-in or out, in treatment room etc.). | |
6.3 | The system shall provide statistics for appointments such as: no-shows, left without being seen, etc. | |
BN 7: Reporting—The system should have the capability to produce, display and format reports, and should be able to be saved in various formats such as PDF, CSV, etc. Reports containing personally identifiable information that are required to be transmitted, retrieved, viewed, or printed meet all VA Handbook 6500 requirements. These reports represent the as-is process. It is expected that report requirements will be further defined with the business owners throughout the system development and acquisition process. | 7.1 | General Reporting Needs |
7.1.1 | Ad Hoc Reports—The system shall have the capability to support user-created ad hoc report generation (without re-programming) and provide the capability to save the report definition for future use and to save the reports in various standard exportable formats. | |
7.1.2 | The system shall have the capability to report on scheduling measures and metrics across the VHA at many levels, including but not limited to National, VISN, Facility/Station/Clinic/Community-Based Outpatient Clinic (CBOC), and shall have the capability to “roll-up” data from the most granular level (i.e. clinic or station level) to the highest level for reporting purposes (i.e. National level) as defined by the business. | |
7.1.3 | The system shall have the capability to establish and ensure the use of consistent metrics and measures across different areas of the VHA; i.e., ensure that all business level facilities measure, capture and report the same data in the same ways. | |
7.2 | Operational reports are generated by a facility, VISN, station or clinic to facilitate day-to-day operations. These can range from printing daily appointment lists for a clinic to printing a listing of patients who missed appointments or who left without being seen. Operational reports are also generated to track performance metrics, access to care metrics, utilization of staff, workload measurement/workload leveling and workload planning. | |
7.2.1 | The system shall have the capability to generate and display a work list based on unfulfilled appointments at the operational level to capture the source of a request, type of request, and status of a request along a timeline. Work list (queue) is automatically updated based on tasks that need to be completed by the scheduler. |
Attachment B—Scheduling-Related and VA-Specific Requirements and Point Allocations
Requirement | Description | Points |
---|---|---|
1 | The system shall have the capability to provide for the enforcement and modification of national-level data standards including procedure and diagnosis codes as currently defined in VistA | 3 |
2 | Flexible Schedule Component Organization—The solution shall have a mechanism to oversee and manage potential impacts to the system as a result of policies, directives, etc | 5 |
3 | The system shall provide the flexibility to accommodate new functional requirements based on business needs (e.g., primary care home (PACT) based care appointments, telehealth, etc.) | 5 |
4 | The system shall have the capability to alert VA staff when appointments are scheduled about patient scheduling reliability (show/no-show rate) averaged over a period of time configured by the authorized end user | 3 |
5.1 | The system will, when managing the appointment selection process, shall have the capability to capture the desired date for the appointment | 5 |
5.2 | The system shall allow for administrative closure of consults | 1 |
5.3 | The system shall have the ability to integrate unscheduled CPRS consults with the scheduling system | 2 |
6 | The system shall associate each appointment type with the correct DSS stop code/credit stop; see: http://www1.va.gov/vhapublications/ViewPublication.asp?pub_ID=1788 | 5 |
7.1 | Telehealth—The scheduling system shall provide the capability for national Clinical Video Telehealth (CVT) scheduling which ensures resources at multiple ends of a telehealth visit are coordinated with the patient across different VistA systems and capture workload data | 5 |
7.2 | The system shall have the ability to capture whether appointment is scheduled vs. unscheduled to support travel reimbursement determination | 3 |
7.3 | The system shall provide reports for consults obtained outside of VHA | 5 |
8 | The system shall have the ability to disposition for travel reimbursement | 3 |
9.1 | The system shall have the capability to generate reports containing scheduling data from both the solution application and legacy systems | 3 |
9.2 | The system will collect currently used wait time metrics including create date and desired date, scheduled appointment date and completed appointment date | 5 |
9.3 | National Reports: National reporting is generated by national program managers, VISN management and by facility management to review performance, trends, analytics, as well as access to care and payment issues. National reports are populated by “rolling up” information from the various stations, clinics, and facilities across VHA | |
9.3.1 | The system shall have the ability to capture and provide the data necessary to conduct capacity planning through complete visibility into supply (provider, equipment, facility, support staff) and demand (enrolled and/or empaneled Veteran requests for appointments) | 3 |
9.3.2 | The system shall have the capability to generate wait time metrics and measures based on clinic operational metrics | 5 |
9.3.3 | The system shall have the capability to generate reports based on cost reporting metrics and measures (i.e. DSS stop codes and other financial metrics and measures as defined by the business) that are tied to the scheduling appointment. Examples of existing reports include, but are not limited to the following: | |
• DSS Outpatient Encounter and Workload | 3 | |
9.3.4 | The system shall have the capability to generate reports based on provider utilization and provider credentialing | 3 |
9.3.5 | The system shall have the capability to generate performance reports. Performance measures include access measures, clinical measures and scheduling measures | 5 |
9.3.6 | The system shall have the capability to generate patient complaint tracking and status metrics and measures reports. Examples of existing reports which work now and must continue to work include (but are not limited to) the following types of reports: | 3 |
• Survey of Healthcare Experiences of Patients (SHEP) Inpatient and Outpatient Survey Reports | ||
• Patient Advocate Profiles | ||
• Number of Complaint Issues by Type of Care Patient Advocate Tracking System (PATS) | ||
• Summary of Responses to Patient Complaint Data in Outpatient SHEP (OQP) | ||
• Compliments/Complaints as % of Total (PATS) Report | ||
• All Complaint Issue Trending (PATS) | ||
• Complaint Clinical Appeal Data (PATS) | ||
9.3.7 | The system shall have the capability to generate reports based on metrics and measures related to Clinic Resources as defined by the business | 4 |
9.3.8 | The system shall have the capability to generate on-demand reports containing current data to be presented to Congress | 5 |
9.3.9 | The system shall have the capability to generate reports based on metrics and measures related to Mental Health appointments | 5 |
9.3.10 | The system shall have the capability to generate reports based on Workload and Utilization Management metrics | 5 |
9.3.11 | The system shall have the capability to generate reports based on unfulfilled appointment request | 5 |
9.4.1 | The system shall have the capability to generate reports based on metrics and measures related to Workload management at the local level | 3 |
9.4.2 | The system shall have the capability to generate reports based on metrics and measures related to patient information relevant to supporting the episode of care, the continuity of care, and missed opportunities of all patients | 5 |
9.4.3 | The system shall have the capability to generate reports based on metrics and measures related to appointments and clinics, including availability and utilization, case load, cancellations, check-ins, general/random appointment information, notifications and letters, and audits by supervisors | 5 |
9.4.4 | The system shall have the capability to generate QA reports to ensure the proper disposition of incomplete appointment information | 5 |
Examples of current reports that rely upon this data and must be maintained include, but are not limited to, the following: | ||
• Encounter Activity Report | ||
• Encounter `Action Required' Report | ||
• Means Test/Eligibility/Enrollment Report | ||
• Outpatient Encounter Workload Statistics | ||
• Performance Monitor Summary Report | ||
• Performance Monitor Detailed Report | ||
• Trend of Facility Uniques by 12 Month Date Ranges | ||
• Error Listing | ||
• Transmission History Report—Full | ||
• Transmission History for Patient | ||
• Scheduling/PCE Bad Pointer Count | ||
• Alpha List of Incomplete Encounters | ||
• Incomplete Encounter Error Report | ||
• Summary Report—IEMM | ||
• Correct Incomplete Encounters | ||
• Provider/Diagnosis Report | ||
• Visit Report by Transmitted OPT Encounter | ||
9.4.5 | The system shall have the capability to generate reports based on metrics and measures related to diagnostic and procedural information that ranks each by frequency and for a specific date range. Examples of current reports that must be maintained include, but are not limited to, the following: | 3 |
• Outpatient Diagnosis/Procedure Frequency Report | ||
• Management Report for Ambulatory Procedures |
Attachment C—Non-Functional Requirements
NFR characteristic | NFR sub-characteristic | NFR Statement |
---|---|---|
3.1 Functionality | 3.1.1.8 The Scheduling Solution shall be capable of providing configurable error messages, work flows, and alerts. | |
3.1.2 Accuracy | 3.1.1.11 The Scheduling Solution shall display appointment time with appropriate time zones. | |
3.1.3 Interoperability | 3.1.3.2 The Scheduling Solution shall support content transportation standards and implementation specifications set forth in 45 CFR 170.205. | |
3.1.3.5 The Scheduling Solution shall be capable of navigating seamlessly among related modules throughout the end-to-end scheduling process. | ||
3.1.5 Security | 3.1.5.1 The Scheduling Solution shall be able to support secure messaging. | |
3.3 Usability | 3.3.1 Understandability | 3.3.1.1 The Scheduling Solution shall be self-descriptive and explain itself through cues (e.g., screen, area, and group titles indicating the purpose of the respective interface element; on-screen instructions/diagrams; explanations/answers that are available on request; no implicit assumptions about how users are expected to behave that would contradict users' expectations; and feedback is given on user actions, system actions, and the system state. |
3.3.3.2 The Scheduling Solution shall be usable across multiple operating systems, browsers, and platforms. | ||
3.5 Maintainability | 3.5.1 Analyzability | 3.5.1.1 The Scheduling Solution shall be capable of providing transaction logs, error logs and audit trails for pertinent scheduling transactions. |
3.5.4 Testability | 3.5.4.1 The Scheduling Solution shall provide criteria to enable the measurement to test pieces of code or functionality, or a provision added in software so that test plans and scripts can be executed systematically. |
[FR Doc. 2012-25408 Filed 10-15-12; 8:45 am]
BILLING CODE 8320-01-P