FILE | D | iEHR Pharmacy Solution - Attachment

FBO DAILY ISSUE OF JUNE 02, 2012 FBO #3843
DOCUMENT

D -- iEHR Pharmacy Solution - Attachment

Notice Date: 5/31/2012
Notice Type: Attachment
NAICS: 541511 — Custom Computer Programming Services
Contracting Office: Department of Veterans Affairs;Technology Acquisition Center;260 Industrial Way West;Eatontown NJ 07724
ZIP Code: 07724
Solicitation Number: VA11812I0407
Response Due: 6/21/2012
Archive Date: 8/20/2012
Point of Contact: Michael Weckesser
Small Business Set-Aside: N/A
Description: Description: The Integrated Electronic Health Record (iEHR) Integrated Program Office (IPO), made up of members from the Department of Veterans Affairs (VA) and Department of Defense (DoD), requests a Commercial-Off-the-Shelf (COTS) solution to support iEHR Pharmacy, to include Clinical Provider Order Entry (CPOE) and Clinical Decision Support (CDS), licensing, training, support and maintenance, and testing and installation support as described in the attached Draft Performance Work Statement. The iEHR Pharmacy Solution will support the input, ordering, tracking, and dispension of Pharmacy services already being provided in both the VA and DoD, and provide for seamless transition for hospital to hospital. Introduction: THIS IS NOT A SOLICITATION. In accordance with FAR Part 10, Market Research, and as part of VA's market research process, this is a request for information (RFI) to assist us in developing the Performance Work Statement for the iEHR Pharmacy Solution. This RFI is for information and planning purposes only and shall not be construed as a solicitation or as an obligation on the part of the VA. The purpose of this RFI is to identify qualified sources able to meet VA requirements, to assist in planning possible future technical requirements, determine the appropriate acquisition strategy, and understand commercial pricing practices and other market information readily available. Telephone inquiries and responses will not be accepted at this time since there is no further information available. This announcement is based upon the best information available and is subject to future modification. VA will not be responsible for any costs incurred by responding to this RFI. Background: In January 2004, President Bush issued an executive order encouraging the use of Electronic health records by 2014 with the goal of making health care more efficient. The DoD and VA responded to this challenge and have been national leaders in the development and implementation of enterprise-wide electronic health and benefits records. However, DoD and VA have taken it a step further to sharing of the data between the two clinical systems. To date, both Departments' efforts have centered on creating and developing bidirectional exchange of data to include such initiatives as Bi-directional Health Information Exchange (BHIE), Clinical Data Repository/Health Data Repository (CHDR), Virtual Lifetime Electronic Health Record (VLER) and orders portability at Federal Health Care Center (FHCC), North Chicago. Although these initiatives have increased the amount of clinical data available to the provider for beneficiaries seen in both systems, they have not moved the Departments closer to the 2008 National Defense Authorization mandate for full interoperability of personal health data between the Departments by September 2009. In December 2010, the Deputy Secretaries of DoD and VA directed the development of an integrated Electronic Health Record (iEHR) which would provide both Departments an opportunity to reduce costs and improve interoperability and connectivity. DoD and VA leadership selected Pharmacy to be the first capability to be developed under the iEHR initiative. Development of a joint Pharmacy solution would be the first step in modernizing/ replacing the existing DoD Pharmacy Modules within the Composite Health Care System (CHCS), and the VA Pharmacy Modules within the Veterans Health Information Systems and Technology Architecture (VistA). The goal of this DoD/VA enterprise wide pharmacy system would improve clinical care by providing both Departments with the following: "A single solution to include uniform prescription and medication orders "Improved patient safety for all beneficiaries "Pharmacy inventory management "Enhanced medication reconciliation VA and DoD have agreed upon an iEHR conceptual architecture characterized by many common elements. The architecture is intended to align with the Departments' objectives to improve patient safety, clinician satisfaction, and lower operating costs through joint investments in health IT. The Technical Specifications Package (attached) provides further insight to the technical architecture and enviroments. Information Requested from Industry: In response to the RFI, interested contractors shall submit the following information: 1.Company Information/Socio-Economic Status - a.Provide the company size, the CAGE code, and the POC information (name, email address, telephone, and fax numbers). b.Indicate whether your company, subcontractors, teaming partners, joint ventures have a Federal Socio-Economic status, e.g., Small Business, Service-Disabled Veteran Owned Small Business, Veteran Owned Small Business, Woman-Owned Small Business, Disadvantaged Small Business, and Hub Zone. If Service-Disabled or Veteran Owned Small Business, is your company and or partners registered in VA's VetBiz repository? 2.Background/Past Experience - Provide the following information on a maximum of three similar projects in a healthcare environment completed within the last three years for which the responder was a prime or subcontractor. a.The name, address, and value of each project b.The Prime Contract Type, Firm Fixed-Price, Cost Reimbursement or Time and Material c.The name, telephone and address of the owner of each project d.A description of each project, including difficulties and successes e.Your company's role and services provided for each project. 3.Capabilities/Qualifications - Overview of proposed solution(s). a.Include a description of the capabilities/qualifications/skills your company possesses to perform the work as described in the PWS. b.Identify whether you are the Original End Manufacturer, Authorized Reseller, or an Integrator for your solution. 4.Teaming Arrangements - Description of Teaming Partners, Joint Ventures that your company would consider to perform the work. 5.Other Market Information - Provide any other relative information, however this information must be included within the 20 page limitation. 6.Other Federal Experience - Identify the federal contract vehicles to which you are party. Requirements: 1.Conduct an evaluation of the draft PWS and schedule, and provide commentary and suggestions that you feel would enhance to provide a more complete solution. 2.Review the PWS and provide responses to the following questions: a.Identify the requirements your product does not meet and the level of effort that would be required for your product to meet the requirement. b.Identify, and explain the need for, requirements not currently in the specification that you recommend be added. c.Provide any feedback/comments on all other requirements that you feel does not clearly articulate the Governments requirements. d.Provide responces to the below questions: Licenses 1.What licensing structure do you feel would be best for this Solution? Please explain the advantages of this approach. 2.Do you offer various licensing approaches? For example, do you license based on users, cores, various enterprise licenses, etc? 3.Would the IPO be required to separately obtain licenses through third party vendors? 4.How would your licensing solution be structured for maintenance and support for future releases? Is there any cost adjustments for major or minor upgrades? How do you define a major or minor upgrade? 5.Please describe application software, client access licensing structure as it pertains to user/device licensing model. In a thin client architecture with your application leased per user session, is the license released at the termination of each session and available for the next session request? 6.Are there limits to the number of facilities/users that are accessing the system at any given time, before seeing degrades in performance? CPOE 1.Provided in your iEHR COTS Pharmacy software solution, can Clinical Provider Order Entry (CPOE) be purchased separately? What is the risk of having a separate CPOE? 2.Is your software product tightly integrated/coupled or is it able to be split into separate modules? 3.Is your software able to contribute to a broad CPOE or must it stand alone? 4.Describe how your CPOE and CDS modules support semantic interoperability with multiple vendors and applications. TRAINING 1.What type of training do you offer and how is it structured? (ie. Module based) 2.How are training hours purchased? 3.Is training for updates offered? If so, how do you deliver training for updates? DATA CONVERSION/DATA STORAGE 1.What is your capability and experience with pharmacy legacy data conversion (historical prescription, allergies, etc.)? 2.Does your software application require its own database instance? Is there data that must remain in the associated database? Can data be transferred via an enterprise service bus and integrated with legacy systems? 3.Within your construct, what data would you consider a good fit into a non-relational database? What data would be a good fit into a relational database? INTERFACES 1.Please review the attached list of interfaces found in the TSP. Can you identify which interfaces you currently have? 2.If you currently do not have the interfaces listed, do you anticipate having these interfaces? If so, when? GFE 1.What equipment would you require to provide Tier 3 support? PWS FORMAT 1.For the software requirements in Attachment 1, are you able to respond most effectively to the descriptive paragraphs as listed or would a spreadsheet be preferred? 2.While certain specifics are not available at this time, is the overall concept of the PWS (ie: workflows) understandable? SECURITY: AUTHENTICATION How will your product be able to align with the following: 1.Ability to adopt a Single Sign-on configurability and capabilities (integration to Lightweight Directory Access Protocol (LDAP), Siteminder, AD) 2.Ability to support Security Assertion Markup Language (SAML) Federated security standard - SAML 2.0 3.Ability to accept Common Access Card (CAC) / Personal Identity Verification (PIV) as the authentication mechanism 4.Ability to onboard new users in the systems 5.Ability to off board users from the system SECURITY: AUTHORIZATION How will your product be able to align with the following: 1.Ability to define logical roles in the system 2.Ability to relate logical roles in the system to the physical roles in the enterprise 3.Ability to consume physical enterprise roles 4.Ability to support many to many mapping between physical roles and logical roles 5.Ability to support role inheritance with respect to permissions 6.Ability to support the Health Level 7 (HL7) role based model for pharmacy 7.Ability to identify the user either based on username/password or the X.509 certificate SECURITY: AUDIT TRAIL How will your product be able to align with the following: 1.Ability to capture users performing operations on the system including and not limited to create, read, update and delete (CRUD) 2.Ability to view user logs through a common front end 3.Ability to backup log files to a local file media / remote file media through Hypertext Transfer Protocol (HTTP) type protocol 4.Ability to facilitate multiple levels of logging that can be adjusted without restart of the system 5.Ability to provide end to end view of a user operation from the point the user entered the system to the point where the user left the system 6.Ability to create custom reports that show the user access patterns SECURITY: ENCRYPTION/DECRYPTION How will your product be able to align with the following: 1.Ability to support Secure Sockets Layer (SSL) and consume certificate from a Custodial Agent (CA) 2.Ability to support field level security utilizing a certificate 3.Ability to support message level security utilizing a certificate 4.Ability to support database-level encryption of certain fields DATA MANAGEMENT: DATABASE 1.How will your product be able to align with the following: a.Ability to support data persistence in a relational database management system (RDBMS) b.Ability to support access to database through Java Database Connectivity (JDBC) / Open Database Connectivity (ODBC) DATA MANAGEMENT: DATA FEDERATION 1. How will your product be able to align with the following: a.Ability to scale the database horizontally based on the user needs b.Ability to segregate rich media into content management system c.Ability to integrate with a content management system for rich media d.Maintain consistency of distributed data e.Maintain availability of distributed data f.Maintain partition and fault tolerance of distributed data g.Ability to participate in a federated data architecture DATA MANAGEMENT: SEMANTIC MANAGEMENT 1. How will your product be able to align with the following: a.Ability to map different data formats into the product format b.Visual utility to map from one format of data to another format of data c.Ability to support binary incoming data formats d.Ability to support binary outgoing data formats DATA MANAGEMENT: DATA QUALITY MANAGEMENT 1. How will your product be able to align with the following: a.Ability to support on the fly data cleansing and master data management through industry known rules b.Ability to incorporate custom rules for data quality management c.Ability to provide industry specific rules for data quality management d.Ability to embed other master data management tools through a pluggable architecture DATA MANAGEMENT: OFFLINE/ONLINE 1. How will your product be able to align with the following: a.Ability to sever a piece of data and make it offline to be worked on b.Ability to replicate the data between a server c.Ability to resynchronize the data d.Ability to do automatic conflict resolution for concurrency issues e.Ability to modify the data while offline DATA MANAGEMENT: DATA MAINTENANCE 1. How will your product be able to align with the following: a.Standard support for Data archiving and restoration b.Ability to migrate data from-and-to different databases c.Ability to restore database based on pre-backed up data points CLOUD ARCHITECTURE: PLATFORM AS A SERVICE (PAAS) 1. How will your product be able to align with the following: a.Ability to be deployed into a custom cloud infrastructure b.Ability to work in a virtualized environment c.Ability to support both scaling up and scaling down through the architecture d.Ability to make development modifications that can be automatically synchronized to the cloud e.Ability to move to a cloud oriented database - Key Value Pair / Distributed Hashtables CLOUD ARCHITECTURE: INFRASTRUCTURE AS A SERVICE (IAAS) 1. How will your product be able to align with the following: a.Ability to deployed on commodity hardware b.Ability to consume various pieces of infrastructure as a service such as Data Storage etc. CLOUD ARCHITECTURE: SOFTWARE AS A SERVICE (SAAS) 1. How will your product be able to align with the following: a.Ability to support single-tenant and multi-tenant models for deployment b.Ability to integrate SaaS with the legacy software (i.e. part of the functionality is in the cloud and part of it exists within enterprise legacy systems) COMMON USER INTERFACE: USABILITY 1. How will your product be able to align with the following: a.Ability to personalize UI to individual user needs b.Overall Interface: Flexibility and Ease of Use c.Search, Filter, Sort Features d.Integration with Content Management System for images, video and other rich media e.Administrator User Interface f.Online, Offline, and Mobile Access g.Support for collaboration between users h.Ability to embed the vendor user interface into a mash-up i.Ability to embed other user interface into the vendor user interface j.Ability to interactively show alerts and reminders as they appear for the user k.Ability to support Citrix Type emulation based deployment l.Ability to provide validation for commonly used regular expressions such as Social Security Number (SSN) etc. COMMON USER INTERFACE: USER INTERFACE 1. How will your product be able to align with the following: a.Ability to support a browser only front end b.Ability to support majority of browsers c.Ability to support HyperText Markup Language (HTML) 5 technology d.Ability to orient the fields based on user preferences i.e. move the fields around e.Ability to support properly formed names and addresses for the page and all other resources referenced from it (Uniform Resource Identifiers (URIs)), based upon Request for Comment (RFC) 2396, from Internet Engineering Task Force (IETF). f.Ability to support proper use of HTTP and Multipurpose Internet Mail Extensions (MIME) to deliver the page, return data from it and to request other resources referenced in it, based on IETF. g.Ability to support HTML 5 type interaction through Representational State Transfer (REST) and postmessage h.Ability to support JavaScript based data input and data output i.Ability to support roles based field display j.Ability to support roles based field encryption COMMON USER INTERFACE: ONLINE/OFFLINE 1. How will your product be able to align with the following: a.Ability to access the same user interface while being offline b.Ability to modify the data while offline c.Ability to do shallow validations through JavaScript while offline d.Ability to display conflicts when the synchronization happens SERVICE ORIENTED ARCHITECTURE (SOA)/ENTERPRISE SERVICE BUS (ESB): APPLICATION INTEGRATION 1. How will your product be able to align with the following: a.Ability to exchange data using Synchronous Request/Response exchange pattern b.Ability to exchange data using Asynchronous Request/Response exchange pattern c.Ability to support message level security in accordance with the applicable standards d.Ability to support transport level security as per the applicable standards e.Ability to expose data as SOA Service f.Ability to provide attribute-based access control (ABAC) enforcement at the endpoint level, and at the message level g.Ability to support Event-driven, or Notification-based, interaction pattern for web service interaction h.Ability to support SAML for communicating user authentication, entitlement, and attribute information i.Ability to maintain an inventory of services using a SOA Registry j.Ability to support the software architectural style REST for web services k.Ability to support Simple Object Access Protocol (SOAP) based web services SOA/ESB: WORKFLOW 1. How will your product be able to align with the following: a.Ability to expose business logic as a service b.Ability to support business activity interoperability across trust boundaries by supporting aggregation and correlation of services c.Ability to support web services choreography SYSTEM: BUSINESS RULES/BUSINESS LOGIC 1. How will your product be able to align with the following: a.Object oriented rules definition capabilities (inheritance, etc.) b.Event or data trigger based rule invocation c.Parallel and multi-threaded execution Capabilities d.Graphic User Interface (GUI) or wizard for rule display / development / debugging / deployment e.Capability in Rule categorize / browse / search f.Managing Rule versions g.Capability in Simulation and historical modeling h.Reporting capabilities on Rule Usage i.Atomic Rule Level management capability - development and deployment (script or data) j.Rules system Integration with workflow (if distinct products or hardwired) SYSTEM: WORKFLOW 1. How will your product be able to align with the following: a.Ability to customize the workflow declaratively through a User Interface (UI) b.Ability to consume SOA Services as steps inside the workflow c.Ability to have flexibility to modify the workflow on the fly d.Ability to associate roles to various steps on the workflow / tasks on workflow e.Ability to import a standard Business Process Modeling Notation (BPMN) into the system to be customized as workflow f.Ability to administer a workflow and manage the state of workflow through a user interface g.Ability to onboard the workflow into a Commercial off the Shelf (COTS) workflow tool h.Ability to support various workflow patterns such as scatter gather etc. i.Ability to cancel a workflow on the fly j.Ability to conduct workflow even in an offline environment k.Ability to create reports based on workflow usage BUSINESS ANALYTICS: REPORTING 1. How will your product be able to align with the following: a.Support for built in Canned / structured reports b.Support for integrating to 3rd party Business Intelligence and reporting tools (through data model) c.Inbuilt Creation capabilities for Ad hoc reports d.Presentation capabilities for reports (web, Excel, Portable Document Format (PDF), etc.) e.Delivery of reports (email, File Transfer Protocol (FTP), etc.) f.Supports ODBC/JDBC and native connectivity standards for Oracle, Structured Query Language (SQL) Server, Universal Database (UDB) SDLC: DEVELOPMENT PROCESS 1. How will your product be able for the following: a.Standard Methodology for new product releases b.Standard Methodology for new functionality releases c.Standard Methodology for deploying defect (around customized functionality) releases d.Standard Methodology for deploying defect (generic functionality - across all implementations) releases e.Standard Methodology for deploying technology/ platform and infrastructure upgrades f.Customization capabilities (via custom coding, scripting) g.Customization capabilities (via GUI functions, configurability, Administration) h.Uses standard Development tools/ architecture i.Suitability of technology (i.e. language, Frameworks, Protocols, solution stack) SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC): ARCHITECTURE 1. How will your product be able to support and align with the target iEHR architecture as specified in the Technical Specification Package. Include information pertaining to the following: a.The programming language(s) utilized for the development of software (such as Java, C# etc.) b.The use of a modularized architecture that can be provisioned in a rip and replace fashion c.The ability of the product to expose components through SOA patterns - See ESB / SOA Specification for more details PERFORMANCE 1. How will your product be able to support and align with the performance and Service Level Agreements as specified in the Technical Specification Package? DEPLOYMENT/INFRASTRUCTURE 1. How would you propose deploying your product to yield optimum performance when deployed to a distributed environment supporting multiple facilities? Include information pertaining to, but not limited to, the following: a.Hardware Platform b.Operating System c.Memory requirements SEMANTIC INTEROPERABILITY 1. How do your CPOE and CDS modules support semantic interoperability with multiple vendors and applications? SPECIFIC RESPONSE INSTRUCTIONS: Please submit your response to this RFI in accordance with the following: 1) No more than 20 pages (excluding transmittal page). Include the name, email address and phone number of the appropriate representative of your company; 2) Address each of the sections described below; 3) Submit your response via email to Michael.Weckesser@va.gov; 4) Submit your response by 3:00 P.M. Eastern Time on June 21, 2012; 5) Mark your response as "Proprietary Information" if the information is considered business sensitive. 6) NO MARKETING MATERIALS ARE ALLOWED AS A PART OF THIS RFI. 7) Please submit as one file in Microsoft Word or as a PDF.
Web Link: FBO.gov Permalink
(https://www.fbo.gov/notices/7fbaa279cad16a87e02681b9f1cd16c5)
Document(s): Attachment; File Name: VA118-12-I-0407 VA118-12-I-0407.docx (https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352795&FileName=VA118-12-I-0407-000.docx); Link: https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352795&FileName=VA118-12-I-0407-000.docx; File Name: VA118-12-I-0407 DRAFT_PWS__IEHR_PHARMACY.DOCX (https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352796&FileName=VA118-12-I-0407-001.DOCX); Link: https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352796&FileName=VA118-12-I-0407-001.DOCX; File Name: VA118-12-I-0407 IEHR PHARMACY REQUIREMENTS MATRIX_20120507.XLSX (https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352797&FileName=VA118-12-I-0407-002.XLSX); Link: https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352797&FileName=VA118-12-I-0407-002.XLSX; File Name: VA118-12-I-0407 PHARMACY INTERFACES_V11.XLSX (https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352798&FileName=VA118-12-I-0407-003.XLSX); Link: https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352798&FileName=VA118-12-I-0407-003.XLSX; File Name: VA118-12-I-0407 TECHNICAL SPECIFICATION PACKAGE301450MAY12 V1 5 PWPROTECTED.PDF (https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352799&FileName=VA118-12-I-0407-004.PDF); Link: https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352799&FileName=VA118-12-I-0407-004.PDF; Note: If links are broken, refer to Point of Contact above or contact the FBO Help Desk at 877-472-3779.
Record: SN02762099-W 20120602/120531235216-7fbaa279cad16a87e02681b9f1cd16c5 (fbodaily.com)
Source: FedBizOpps Link to This Notice
(may not be valid after Archive Date)

| FSG Index | This Issue's Index | Today's FBO Daily Index Page |

Loren Data's SAM Daily™

D -- iEHR Pharmacy Solution - Attachment