iEHR Pharmacy RFI --- IS THERE AN OPEN SOURCE SOLUTION?

38 views
Skip to first unread message

stephen hufnagel

unread,
Jun 4, 2012, 11:34:49 AM6/4/12
to Hardhats
You are encouraged to bid individually or we can form an Open Source
consortium through OSEHRA

CALL FOR INTEREST & PARTICIPATION: The iEHR program will be issuing
Requests for Information (RFIs) in June on Laboratory, Pharmacy and
Immunization. Requests for Proposals (RFPs) will be issues around
labor day. Immunization Management seems to be a perfect opportunity
for the Open Source Community, including interested VA developers, to
come together with repurposed VistA, CHCS and other Open Source
alternatives to a purely commercial solution to iEHR capabilities/
applications. If there are open source alternatives to laboratory and
pharmacy, we can also pursue open source alternatives to ancillary
services. This is an opportunity for the Open Source community to take
action and make Open Source VistA relevant to the iEHR way ahead.
OSEHRA, as a non-profit organization and cannot respond/bid on
government contracts; but, the open source community can. As
information becomes available I will bring it to you through the
OSEHRA Architecture Work Group (AWG). I would like to identify
interested Open Source companies or individuals interested in
responding to the RFIs and RFPs and possibly set up a consortium or
strategic partnership among the “coalition of the willing”. There are
approximately 56 iEHR capabilities, which will go through the RFI and
RFP process and I want to insure that the open source community has an
opportunity to participate! We will also start discussing this as part
of the OSEHRA AWG weekly calls

if you are interested in responding to the iEHR RFIs and RFPs as
individuals or organizations, please contact shuf...@tiag.net ,
703-575-7912-cell.

Thank you for your help and consideration,

Steve Hufnagel



D--iEHR Pharmacy Solution

Solicitation Number: VA11812I0407

Agency: Department of Veterans Affairs
Office: VA Technology Acquisition Center
Location: VA Technology Acquisition Center

https://www.fbo.gov/index?s=opportunity&mode=form&id=7fbaa279cad16a87e02681b9f1cd16c5&tab=core&_cview=0

Response Date: 21 June 2012



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....@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.
Please consult the list of document viewers if you cannot open a file.
Attachment
Type: Other (Draft RFPs/RFIs, Responses to Questions, etc..) Label:
Attachment
Posted Date: May 31, 2012
https://www.vendorportal.ecms.va.gov/FBODocumentServ...https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352795&FileName=VA118-12-I-0407-000.docx
To copy full link address, right-click and select "Copy Shortcut" or
"Copy Link Location."
Description: VA118-12-I-0407 VA118-12-I-0407.docx
https://www.vendorportal.ecms.va.gov/FBODocumentServ...https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352796&FileName=VA118-12-I-0407-001.DOCX
To copy full link address, right-click and select "Copy Shortcut" or
"Copy Link Location."
Description: VA118-12-I-0407 DRAFT_PWS__IEHR_PHARMACY.DOCX
https://www.vendorportal.ecms.va.gov/FBODocumentServ...https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352797&FileName=VA118-12-I-0407-002.XLSX
To copy full link address, right-click and select "Copy Shortcut" or
"Copy Link Location."
Description: VA118-12-I-0407 IEHR PHARMACY REQUIREMENTS
MATRIX_20120507.XLSX
https://www.vendorportal.ecms.va.gov/FBODocumentServ...https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352798&FileName=VA118-12-I-0407-003.XLSX
To copy full link address, right-click and select "Copy Shortcut" or
"Copy Link Location."
Description: VA118-12-I-0407 PHARMACY INTERFACES_V11.XLSX
https://www.vendorportal.ecms.va.gov/FBODocumentServ...https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=352799&FileName=VA118-12-I-0407-004.PDF
To copy full link address, right-click and select "Copy Shortcut" or
"Copy Link Location."
Description: VA118-12-I-0407 TECHNICAL SPECIFICATION
PACKAGE301450MAY12 V1 5 PWPROTECTED.PDF
Contracting Office Address:
Department of Veterans Affairs;Technology Acquisition Center;260
Industrial Way West;Eatontown NJ 07724
Point of Contact(s):
Michael Weckesser
732-578-5496

Reply all
Reply to author
Forward
0 new messages