Loren Data's SAM Daily™

FBO DAILY - FEDBIZOPPS ISSUE OF FEBRUARY 19, 2017 FBO #5567
DOCUMENT

D -- RFI for eHMP Commercialization - Attachment

Notice Date

2/17/2017
 

Notice Type

Attachment
 

NAICS

541519 — Other Computer Related Services
 

Contracting Office

Department of Veterans Affairs;Technology Acquisition Center;23 Christopher Way;Eatontown NJ 07724
 

ZIP Code

07724
 

Solicitation Number

VA11817N1908
 

Response Due

3/6/2017
 

Archive Date

5/5/2017
 

Point of Contact

Brandon Caltabilota
 

E-Mail Address

5-1114<br
 

Small Business Set-Aside

N/A
 

Description

6 RFI: Commercialization of Capabilities from VA s Innovative Health Information Technology (HIT) Platforms Purpose This RFI seeks to inform VA s strategy to commercialize or acquire commercial capabilities similar to those developed and planned for HIT platforms such as the Enterprise Health Management Platform (eHMP), to support continuous VA innovation addressing somewhat unique mission challenges, while minimizing acquisition risk and maximizing probability of robust markets for capabilities and content that VHA needs. Mission challenge VHA is committed to providing improved experiences for Veterans and clinicians. To meet this challenge of more holistic, improved care for more Veterans, VHA needs to transform our healthcare delivery practices. One part of this transformation is deployment of evidence-based, standardized practices that allow faster achievement of Veteran-specified health-related experiences at lower cost. Deployment and management of improved clinical practices requires significant improvement over existing HIT for process management and care coordination. In other words, VHA needs HIT that supports more models of care that are intensively Veteran centric, team based, and quality driven. Additional background is at the end of the RFI. That background also explains what is meant by content, which includes decision support algorithms, data entry forms, order sets, and detailed, modeled business processes. Overview of eHMP eHMP is an intelligence platform and user experience that can sit on top of any number of electronic health record (EHR) systems and provide clinicians with decision and process support against the longitudinal electronic health record of the patient. It has three main tiers: longitudinal database, service-oriented architecture (SOA)-style intelligence applications, and user interface. eHMP v1.2 is currently installed to work with all VA VistA instances. eHMP v2.0 is in production testing and is scheduled for broad rollout in 2018. Moderately detailed information can be found at https://www.osehra.org/content/ehmp-architecture. We plan to release a more recent system design document soon. Assumptions VHA positions VA has not yet made a decision for its EHR strategy. This RFI is not intended to inform VA decisions in the near term for eHMP hosting and development. VHA will prioritize IT investments outside core EHR functionality on fill, bridge, and simplify. We aim to fill gaps in high-priority functionality; bridge current and future systems to both allow value from investments now to carry into the period with the new EHR and also smooth the transition to new EHR; and simplify our HIT product space by retiring products that have similar functionality to eHMP. VA is committed to open standards including those promoted by Healthcare Services Platform Consortium (HSPC), Health Level 7 (HL7), Fast Healthcare Interoperability Resources (FHIR) and Object Management Group (OMG). IT acquisition priority is commercial off the shelf (COTS) first. VA funding for development of new capabilities will continue, the actual amount is unknown at this time. VA requires Section 508 compliant and user friendly products (https://section508.gov). VA has a tremendous amount of legacy data that is important for ongoing benefits and health missions of VA. Electronic health data dating back to the year 2000 is relevant. General A healthcare organization s most important HIT partner is their EHR vendor. Vendors will only commercialize what they can and want to sell to others. VA assumes that the backlog prioritization of capabilities for the platform backlog will be different for VA and vendor/development partner. The costs and benefits related to organizational change management far outweigh those for technical acquisitions and integration. The largest benefit to VA from commercialized eHMP functionality will be from access to a large and robust content market for clinical process, decision support, and analytical workflows. (Responses limited to technical and functional capability and without regard to the content market will not be very helpful.) Straw-man approach. The below is a rough outline of how we think a commercialization partnership could work. This is not a decided approach. We put this here as an example only. We welcome alternatives. VA establishes a commercialization partnership through some sort of contractual instrument (e.g. CRADA, Cooperative Agreement, etc), which specifies IP disposition and scope of work. VA may or may not have current authority for such an instrument. VA-developed code is open source and vendor-developed code is proprietary. VA would receive special licensing arrangement for the commercial baseline product. The instrument specifies the timing and licensing conditions for which eHMP functionality will be made available to VA as part of a commercial product by what time and outlines a transition pathway from custom to commercial platform. Eventually, the commercial platform will be mature enough for VA to develop eHMP-like functionality directly in the framework of the partner s product using, for example, a software development kit. In some cases later on, VA-developed functionality will directly become part of the product s commercial baseline. Some later testing and deployment stages will be assumed by the development partner. This could require a new contract structure comparted to current eHMP contract. VA will continue to develop functionality to meet VHA requirements through eHMP contract. During the period in which eHMP is a distinct framework from the commercial product, eHMP functionality will need to be deprecated, when the same functionality is deployed in the commercial product. New eHMP functionality will be designed to minimize cost of feature deprecation and reduce Organizational Change Management costs associated with our final EHR modernization direction. Questions Assess viability of intended outcomes for commercialization of eHMP: Cost, benefits, schedule, and execution risk. Would commercialization create positive return on investment (ROI) faster or increase it more over time? Please consider both technical and organizational change-management costs. What are risk and mechanics for organizational and technical change management as functionality transitions from custom platform to commercial platform? What are alternatives to eHMP commercialization and the attendant risks? How will eHMP commercialization promote the types of interoperability standards that HSPC is promoting? Assess viability of intended outcomes for commercialization of eHMP: Risk of capability acquisition, testing, and deployment. How can VA maximize its ability to continue to add leading, custom functionality in a commercialized platform? (VA does not want to fork the code and maintain its own platform.) Other than custom development, how can VA ensure that the commercialized product continues to meet VA needs over the long run? What does the roadmap look like for switching from the current custom development to baselining on a commercialized platform, specifically accounting for a possible migration to a commercial EHR in the next several years? How are responsibilities divided between VA and development partner for testing and deployment and how do they change over the maturation period of the commercialized platform? Provide guidance on approach to commercialization partnership. What are legal frameworks for an effective commercialization and development partnership? For example, one thought is that VA could establish a CRADA, Cooperative Agreement, etc. with development partner and a separate custom-development contract with shared governance of backlog. What are the mechanics of the relationship that we need to consider, facilitate, and defend against? How should/would the vendor/development partner take eHMP to market? Assess potential partners: Is there a viable alternative to the VA s EHR vendor as the development partner that can be trusted to create the market for the commercialized product and content? If VA partners with someone other than the EHR vendor, what are the risks and how would we mitigate them? For example, a major risk is that we select a commercialization partner that is not our EHR vendor; our EHR vendor releases part of the functionality that commercialized product has; VA faces user experience (UX) and workflow complications of multiple products. What are characteristics of a viable partner for product development and market creation? React to these goals for eHMP commercialization: Accelerate the market for content that includes evidence-based computable clinical pathways. Focus VA development of clinical HIT on fill-bridge-simplify functionality, thus improving ROI. Relieve VA from maintaining software, thus lowering costs and strain on human resources. Allow VHA to benefit earlier and at lower cost from functionality that the development partner will add to its product based on acceleration of its own backlog. (If other products by other vendors have the same functionality, adding functionality to the platform of the development partner would allow VHA to benefit from the functionality in a more integrated UX.) Promote interoperability standards such as those championed by HSPC. Additional Background Technical history: For decades, VA has been using a custom EHR called VistA with a Delphi-based front-end called Computerized Patient Record System (CPRS). The technical foundations of VistA are solid, and CPRS has won many accolades. VA has 130 instances of this EHR, each of which is somewhat but significantly different. The differences in data and business logic result in significant heterogeneity of clinical practices and make it difficult to standardize them. Starting in 2010, VA developed an open-source strategy to modernize the health-related components of VistA and add more modern components. The program, currently called VistA Evolution, manages this strategy. It has demonstrated success in both of these areas. VistA improvements include standardization of code and providing APIs. New capabilities from modern technical components have been delivered through the eHMP. However, data and business logic has not been standardized across the VistAs. Custom-technology challenges: Since VA decided on open-source VistA modernization and platform development seven years ago, HIT markets for technology and labor have significantly changed. Subsequent to the American Recovery and Reinvestment Act of 2009, investment in commercial EHR systems has soared, while investment in VistA has remained relatively flat. VA s access to a pool of highly-qualified technical personnel will continue to be a challenge. Content challenges: To support the business transformation that VHA requires above, information technologies will require a large volume of continuously improved, evidence-based content. This content includes decision support algorithms, data entry forms, order sets, and detailed modeled business processes. VHA and federal partners will not be able to generate and maintain the required content on their own. Similar to markets for technology, VHA will need to draw on robust markets for content. VHA and other leading healthcare systems believe that robust markets for content require that it be platform independent and computable. That is, the content can be encoded in a standardized notation, so it can be compiled and run on various technical platforms. A mature market will also include tooling that allows provider organizations to participate in continuous evolution, quality-control, and risk-management of the content. Organizations such as HSPC are working with standards development organizations on semantic and notation standards that allow a standardized representation of the content and reliable execution of the content using data native to provider organizations. However, such standards-based, computable content is not currently available at volume. VHA needs to develop and deploy standards-based content now that can also be used in conjunction with or by its EHR later. VHA does not want to develop content multiple times to fit capabilities of various HIT systems. Changing the content to fit certain HIT solutions often results in workflow changes that, over hundreds of thousands of employees, result in significant-change management costs. Commercial technology gaps: VA is currently considering courses of action for improving its core EHR capabilities and intends to announce this strategy this summer. However, VHA does not see that current commercial EHR suites have the necessary functionality to support VHA in the business transformation necessary to meet its extreme challenges described above. Whereas EHR or other companies are likely to develop viable products and make them available three to six years from now, VHA needs something like eHMP today. VA would like an option to license a commercial, standards-based intelligence platform similar to eHMP that provides robust team and process management. VHA is not aware of current products with a viable market share that could replace eHMP and vended by companies capable of acquiring a significant market share to ensure continued development of eHMP-like capabilities and supporting content. VHA has targeted a number of business problems for eHMP. The primary target is development and enterprise deployment of evidence-based, standardized clinical processes that allow all members of a team to operate at the top of their licenses. This is essentially applying manufacturing principles to healthcare for shortened cycles at reduced costs for productivity, aka realization of Veteran s health-related goals. A future, related component is activity-based costing and productivity assessments. Secondary problems for eHMP include a better UX and cohort management. eHMP provides a UX that is both more enjoyable and provides better support for a variety of clinical workflows than CPRS. Cohort management is about dynamically defining a cohort of patients, determining how to better address their needs through a defined or dynamic investigative workflow, and intervening in groups of patients or individual patients. Cohort management also includes all registry functions. eHMP does not now have functionality for cohort management. VHA also wants to use eHMP as a bridge between existing and future EHR systems. We want eHMP to deploy new clinical practices now and continue to use eHMP-like functionality for these clinical processes through the EHR deployment. There are technical, semantic, and process interoperability requirements that EHRs must meet for eHMP to be as effective as with VistA. Instructions for Submitting Questions and the RFI Response: The VA Technology Acquisition Center points of contact for this RFI are Contract Specialist, Brandon Caltabilota and Contracting Officer, Mark Junda. Submit any questions to this RFI directly to Brandon Caltabilota at Brandon.Caltabilota@va.gov and Mark Junda at Mark.Junda@va.gov. RFI responses are to be submitted directly to Brandon Caltabilota and Mark Junda by 12:00 PM Eastern Standard Time, March 6, 2017. If possible, please limit responses to 15 pages or less. All proprietary/company confidential material shall be clearly marked on every page that contains such.
 

Web Link

FBO.gov Permalink
(https://www.fbo.gov/notices/36aa9f9c300f4bc84cda2f2c029ac989)
 

Document(s)

Attachment
 

File Name: VA118-17-N-1908 VA118-17-N-1908.docx (https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=3285986&FileName=VA118-17-N-1908-000.docx)

Link: https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=3285986&FileName=VA118-17-N-1908-000.docx

 

Note: If links are broken, refer to Point of Contact above or contact the FBO Help Desk at 877-472-3779.
 

Record

SN04406927-W 20170219/170217234315-36aa9f9c300f4bc84cda2f2c029ac989 (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 |