Search for iEHR FBO Changes in the last Week:,mod=14&sourceid=chrome&ie=UTF-8&,or.r_gc.r_pw.r_cp.r_qf.,cf.osb&fp=2db105060e3663e9&biw=1920&bih=919

Search active VA RFP's:


RFI Lab Support

Solicitation Number: TMA-iEHR-RFI-06-2012

Office: TRICARE Management Activity

Notice Type: Sources Sought

Posted Date: June 12, 2012

Response Date: Jul 12, 2012 5:00 pm Eastern

 Purpose:This Request for Information (RFI) is to solicit preliminary information from vendors who can advise the Department of Defense (DoD) and the Department of Veterans Affairs (VA) on solutions for a critical need related to the integrated Electronic Health Record (iEHR) Clinical Laboratory and Anatomic Pathology initiative.  Link: 



RFI iEHR Pharmacy

Solicitation Number: VA11812I0407

Agency: Department of Veterans Affairs

Office: VA Technology Acquisition Center

Notice Type: Sources Sought

Posted Date:June 6, 2012

Response Date:June 25, 2012

Purpose: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. 




I see a problem with this

Carol Monahan's picture

I would like to hear other folks' reactions to this section of the Pharmacy RFI:

"3.0 Scope of Work

The Contractor shall provide 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 herein. The Contractor will be responsible for supporting the selected integration vendor in the performance of said activities. 

The Contractor will not be responsible for development and implementation activities required for integrating the COTS with other systems These activities will be performed by a separate vendor that will be determined at a later date.



The total Period of performance for this effort is eight (8) years consisting of a base period with multiple optional tasks."


If I'm not missing something, this boils down to:

1) They are going to purchase an "off-the-shelf" solution.

2) They're going to go looking for someone else to make it work, after they've selected and purchased it.

3) It will take 8 years (at least).

Overall, the approach of picking out and starting to work with a Pharmacy module without having the underlying patient record system even properly described seems, in the terminology of evolution, a bit "survival negative". 

I'm eager to hear everyone else's thoughts.



RFI / RFP - Maximizing complexity

Rafael Richards MD, MS's picture

Separating the development of any module to one contractor, and integration to another independent contractor creates two independent proprietary module dependencies.  Does this methodology scale?  Absolutely not.  For each N new modules,  the number of proprietary connector modules required is N^2.


This is precisely the conclusion  the PCAST report came to regarding an SOA approach to systems and data integration:

(page 40):  "...To draw a loose analogy, the approach is like trying to enable free trade among hundreds of entities by negotiating a huge number of bilateral trade agreements. Or it is like trying to promote dialog among speakers of a thousand different languages by training one million translators, each knowing a pair of tongues, instead of enabling them to speak a common language. The idea is laudable but impractical. Moreover, the approaches will not overcome the barriers to entry for innovators wishing to develop new solutions."

The VA will have difficulty to change these proprietary modules and their connectors for both technical and licensing reasons.  Change control of any module, particularly one that interacts with any other modules (which it should, since it is an integrated system) will be in the form of  N^2 license-locked binaries of various languages.  This is indeed "survival negative".

So how should the RFI's be worded to manage scalability? to enable smaller players to contribute? to assure code quality?  to engage the open-source community? to maximize innovation? to emplly agile development?

   1.  A single, common language for back-end code

     (M, while is uncommon in general, is the standard for HIT)
   2.  A single, common language for front-end development

     (an open-source web framework at minimum)
   3.  A single, common database 

     (NoSQL, web-scale, federated database)*
   4.  All code  reviewed and tested by  OSEHRA  code testing platform 

     (quality assurance and quality of documentation)
   5.  All code pushed to the OSEHRA code repository

     (long-term maintenance, changes, and development)

Other thoughts?




it's like I'm in that recurring train wreck movie....

Tom Munnecke's picture

There was a movie a while back about a guy who kept travelling back in time to get stuck in the same train wreck.  This is the 4th or 5th time I've been through this VA/DoD sharing process, and it's we are fighting the same battles over and over again.  Every decade or so, Congress gets upset and huffs and puffs at the Secretaries, who promise to work together, then ask for more money to build a bigger bureaucracy to make it happen.

A couple of points:

1.  I'm wondering if we aren't actually dealing with an N-cubed level of complexity, rather than just N-squared.  It's not just the inter-module binaries to deal with, but the organizational context within which the software is embedded.  VistA, as VA Medical Center Chief of Staff Ross Fletcher so eloquently describes, and Philip Longman writes about, is more than just lines of code.  It is a whole community of users, a tool for organizational transformation, and a new way of looking at clinical care.  This, of course, is below the radar of the central IT folks, who only see the geeks-eye view of the world.  So, I would put all of the organizational transformation and clinical improvement of the VA over the past 30 years at risk in this exploding complexity model.  Add in dependencies on standards bodies that are external to the VA and DoD, privacy, changes in laws and administrations, and we're way up in to the N-cubed complexity level.  And, lest we forget we're talking about real patients and real hospitals here, Peter Drucker called the hospital the most complex organization in modern society. 

2.  The notion that IEHR can prove the scalabilty of its architecture by testing it in two places is a bit like proving that an intercom works between two offices.  Two intercoms, one wire... very simple,  And three intercoms and three wires isn't too complicated, either.  But try for 10 intercoms and we end up with 45 wires, and so on at N(N-1)/2 wires.  Its impossible to draw any conclusions of the issues of scale while looking only at N=2

3.  It's even more insidious to look at early costs and presume that they will reflect life cycle costs.  Every vendor, particularly since they don't have to worry about up front integration costs, will lowball their going-in price, planning to make their profits in the change order process after they get their camel's nose into the tent.  The more complicated their solution, with more hidden complexities that require change orders down stream, the more money they will make.  And with so many other vendors to point fingers at for their non-performance, it will be impossible to sort out who is responsible for what snafu.  So, the N-squared (or cubed) dynamic becomes a very profitable activity for the contractors.

4.  The whole IEHR architecture is based on the enterprise perspective... essentially, automating the organization chart.    And doing so at a mega-centralized inter-agency level.  You have to squint real hard at the documents to see anything related to the patient.  This, of course, is a 180 degree turn from VistA's patient focus, or Ken Kizer's quip about transforming the VA as putting "the patient is the center of the health care universe."  IEHR flips this over to "The bureaucracy is the center of the health care universe." 

5.  It would be nice to adopt an evidence-based architecture approach.  When some committee proposes something, they would have to scout the history of the situation to see if this idea has already been tried or not.  If they all agree to some salesman's pitch about "best of breed" approach, then let them study the record to see if and where it has ever worked.  This shouldn't be done in a spirit of self-righteous indignation, but rather an objective "After Action Report" or "lessons learned" assessment.

6.  I might point out that since speaking out against the IEHR approach, I have had a rash of very positive comments from people in the industry, saying things like, "I agree with you, but can't say so because it would jeopardize our business." 

Runaway bureaucracies have no known natural predators.  I think that openness - in the broadest senses of software, government, transparency, content, and communication - is the only way we are going to prevent yet another trainwreck in federal health IT.