OSEHRA Proposes Visionary Open Digital Health Platform for the VA

Roger A. MaduroThe Veterans Health Administration (VHA) recently released a Request for Information (RFI) calling for advice on how to build an open, "interoperable digital health platform." The RFI received 40 responses. Only one of those was publicly released, the one from OSEHRA. That the open source EHR organization was the only one that has been open in their submissions, by itself, tells a story. There are some in the VA proposing replacing the open source VistA EHR with a "Commercial" lock-in product. Proprietary EHR vendors are circling the VA like sharks smelling blood in the water, and they don't want the public to know what they are up to. This article provides good background on the current situation. 

Luckily OSEHRA is the one organization that understands how to modernize VistA. VistA has been successfully implemented by more than 1,000 medical facilities outside of the VA medical system and its capabilities are growing in leaps and bounds. Implementers include the Kingdom of Jordan, the States of New York and Tennessee, all the way to private sector hospitals such as Oroville Hospital in Northern California. In addition, over the past couple of years, OSEHRA has been expanding its mission from an organization focused on VistA, to an organization that embraces and represents all of open health IT. This transformation was reflected in the last OSEHRA Summit this past June when the first day of the conference was focused on Global Health IT and included participants from multiple open health solutions, such as OpenMRS and the OpenEHR community.

The full text of the VHA RFI can be found here. Below is an excerpt outlining the key concepts behind the Digital Health Platform the VA is looking for:

"...the Veterans Health Administration (VHA) desires a Next Generation Digital Health Platform that is integrated, future-proof and optimizes the cost of operations. To achieve these goals, VA is considering establish an interoperable digital health platform that leads to Easier Access to Care for the Veteran, Better Outcomes for the Veteran and more efficient operations for the VHA. The platform needs to seamlessly support key processes in the following core business areas:

  • Veteran Engagement
  • Clinical Care Management
  • Healthcare Operations Management
  • Health and Operational Analytics

Addressing only one part of the problem such as establishing an Electronic Health Record for the Clinical Care Management process without accounting for its relationship with other systems such as a Supply Chain system will have but only a limited impact to the problem VA aspires to solve. VA anticipates a need to adopt a platform approach to accomplish this objective. The proposed architecture for the Next Generation Digital Health Platform takes this into account and goes beyond the Electronic Health Record and includes five strategic, integrated components:

  • One Electronic Health Record system (EHR),
  • One Operation Management Platform consisting of one resource allocation, financial, supply chain, and human resources system that are integrated seamlessly with the EHR,
  • One Customer Relationship Management (CRM) system,
  • One Analytics system,
  • One Open Application Programming Interface (API) Framework that provides seamless interoperability with internal and external systems..."

The OSEHRA response below. Note that OSEHRA conducted multiple community calls in preparing their response and received a number of written suggestions from members of the community. Roger A. Maduro. Publisher and Editor-in-Chief, Open Health News.

 

 

 

Response to RFI VA118-17-N-1646

Open Digital Health Platform Strategy

Executive Summary

The U.S. Department of Veterans Affairs has been at the forefront of conceptualizing, developing and adopting a variety of innovative services and technologies related to care delivery for many decades.  This new bold design for an Open Digital Health Platform (ODHP) has many attributes that can not only restore VA’s leadership in health IT, but also establish a context for integrating management and service delivery throughout the enterprise.  Some of the core concepts, such as extending into communities throughout the United States, future-proofing, adoption of open standards, and public-private partnerships reflect VA’s commitment to the adoption of modern technology and state-of-the-art open technology management.

The concepts in this RFI are also highly congruent with Executive Memorandum M-16-21, which establishes a new Federal policy on open source.  The new policy aims to achieve high efficiency of code reuse by the entire community of government agencies and the private sector. VA and the open source community have had significant successes in open source innovation that include the upgrade to Fileman, a highly successful collaborative Immunization project, an ongoing code intake process, and multiple open community engagements.  The recent launch of the follow-on eHMP effort as an open and agile project is one of many indications that VA has embraced open, agile innovation as an organizational strategy in this new era.  This RFI response is informed by five years of community building and open source operation.  While much of our experience is centered on the electronic health record component, the lessons learned are equally applicable at the platform level.  Thus the OSEHRA Community is offering suggestions that will not only enhance the probability of a successful, sustainable implementation, but also continue VA’s leadership in complying with Federal open source policy.  For example:


  • Foundational technology such as an ODHP should be based on open source, open architecture, open standards, and open collaboration.  If the proposed platform is to be future-proof, VA needs to implement additional changes in its cultural and contracting approach to development to accommodate and encourage community participation from inception.  This will not only create a wider support community to enhance sustainability (and “future-proof”), but will also enhance VA’s ability to extend services and capabilities into the community.  The ODHP should be planned from the start as a national asset.
  • The eHMP program currently in progress should become a cornerstone of the proposed platform, and serve as a model for future open, agile development and integration. The current eHMP project should be further modified to conduct at least part of the development in open collaboration with the open source community. 
  • Leveraging open source requires more than simply distributing code and using a few open source products. It involves systematic changes throughout the full lifecycle management of products and services. Open source should not be an afterthought. Open collaboration, community input, and public-private partnership in sustainment should be “baked into” the program plan.
  • While many respondents will possess critical skills and experience, no individual contractor can claim to have successfully implement a comparable system.  The combination of supporting the nation’s largest healthcare provider and the second-largest Department in the Federal Government is unprecedented.  The use of open standards and open architecture, together with wide community involvement, will be essential in creating such a platform.  The required approach will dictate evolution in the VA OIT development culture, and innovation in the Technology Acquisition Center.


Since its creation by VA in 2011, OSEHRA has accumulated unique expertise in open source operation as a public-private partnership.  In this document, we draw upon our first-hand experience to recommend that this bold concept of an ODHP can and should be achieved through open source public-private partnerships.  The established infrastructure of the OSEHRA Community can serve as a highly efficient ecosystem for such partnerships. 


1 OSEHRA and Open Source

1.1 The Open Source Electronic Health Record Alliance

In 2011, VA made a strategic decision to embrace public-private partnership as a means to accelerate innovation and reduce life cycle maintenance costs. The initial focus of this strategy was the electronic health record, and VA was particularly interested in engaging the VistA user community to access innovation and expertise in a more interactive manner rather than was possible through rigid contractual processes. The establishment of an open source community around VistA created the opportunity to go beyond simple distribution of the code for reuse.  It allowed the community to contribute new code, bug fixes, enhancements, and other open source code management tools.

To establish, manage, and develop this open source community, VA established an independent nonprofit organization, the Open Source Electronic Health Record Alliance (OSEHRA).  OSEHRA was chartered as a 501(c)(6) membership-based organization to build and support an open source ecosystem that would enable public-private collaboration based upon open source best practices that have evolved in the global IT community over the past 20 years.

VA, together with the OSEHRA community, has addressed a variety of challenges in implementing an open source approach.  Initiating real collaboration between Government and the Community has posed cultural challenges, precipitated changes in internal development processes, and raised contractual issues when paid contractors are part of the project.  VA has systematically addressed these and other emerging issues.

Much of the work that VA and OSEHRA have done so far centers around the existing VistA code base. OSEHRA has also worked with a personal health system and a population health management system. This experience of building and managing an open source ecosystem of software, governance, and community applies to any major software platform--including ODHP. Though we use examples of VistA in making our case, the lessons learned are also critically important to ensure that ODHP is a lasting success.

1.2 New Federal Policy on Reuse and Open Source

In August 2016, the Federal Government established a policy on open source through Memorandum M-16-21.  Entitled Federal Source Code Policy: Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software, the policy will bring about wide adoption of open source throughout the Federal government.  The policy is very consistent with the ongoing open source innovations within VA, particularly the current efforts in community engagement.  In fact, VA’s experience and expertise offer an excellent framework for implementation and achievement of the reuse and community engagement goals of the new policy.

Some observations on this policy are relevant here.  First, we believe the overarching goal of the policy is to make reuse of software efficient and transparent. The policy adopts open source as a technological and business process to enable code reuse.  Second, the policy specifically recommends community engagement and open development.  Finally, the policy is designed to ensure that open source is an integral part of agency policy, rather than an afterthought.  OSEHRA has been working in all three of these areas with VA for years.  Based upon our collective experience we have identified key challenges that VA must overcome, as well as suggestions to improve efficiency moving forward.

Efficient reuse of code requires a new way of thinking about the application of open source. Open source should not be an afterthought. Retroactive open source implementation makes the entire process expensive and inefficient for all users. VA’s attempt to embed open source and agile processes from the beginning of the current eHMP development effort is a strong indication that the lessons we all learned collectively are being applied to improve efficiency.

Compared with other agencies with no experience in open source, VA is years ahead. We believe our five-year experience in open source has laid an invaluable, strong foundation for the success of ODHP.

1.3 Our Approach for OSEHRA Community Response

OSEHRA does not develop software or integrate systems.  Instead, we work to build a community of developers, integrators, clinicians, and other interested parties to promote the concepts of open source and innovative collaboration.  Our response to this RFI is thus based upon the experience and advice of our membership, and OSEHRA’s direct experience as VA’s open source facilitator.  We have chosen to focus on specific aspects of the RFI where open source strategy will be key to VA’s success.

While many of our most important lessons over the past five years have been centered on electronic health records (and VistA in particular), we understand that future health IT and platform solutions will consist of both open source and proprietary products.  That is why it is so important that foundational technology such as ODHP should be based on open source, open architecture, open standards, and open collaboration.  The lessons VA and OSEHRA have learned in the EHR world are equally applicable across the proposed platform.

2 Strategy for a VA Open Digital Health Platform

2.1 VA Leadership in Care Delivery

The VA VistA system is widely regarded as one of the best electronic medical information systems in existence. This HIT transformation of the VA healthcare system is often cited as the largest and most successful healthcare turnaround in US history.

By mid-1990, VA had made unprecedented advances in using existing technology to reform the delivery of healthcare to Veterans, reducing costs and overcoming significant cultural barriers.  However, this has been followed by more than 15 years of stagnation in developing the infrastructure and means for exchanging information between the VA system and the DOD healthcare systems for active military personnel.

VistA was developed in house around an interesting licensing model based on public domain software (similar to open source, but different from what is normally meant by the term in the commercial world).  Lacking a policy-based process for code release, VA chose to release VistA source code to the public under the Freedom of Information Act (FOIA) so that interested parties could have access to the code base.

This “FOIA-VistA” was adopted by a large number of organizations and individuals around the globe.  Some of the most successful commercial electronic health record products today are based on this earlier VistA code.  Subsequently, large health IT corporations were built around the VistA-based products, and they continue to serve customers in the US and abroad. While many of the innovations around VistA were taking place, there was no mechanism for innovations created outside VA to be merged back into the VistA system.  VA did not participate in any community activities, and eventually efforts to build a community failed.

In 2011, VA made a strategic decision to embrace an open source policy that is essentially a public-private partnership model for software as a means to accelerate innovation and reduce life cycle maintenance costs of VistA. VA was particularly interested in engaging the global VistA user community to access innovation and expertise in a more interactive manner rather than was possible using rigid contractual processes. As a result, OSEHRA was established as an open source agent to foster a community centered on VistA.  This created the opportunity to go beyond a simple, one-way distribution of the code for reuse.  It allowed the community to contribute enhancements and open source products back to VA and to conduct collaborative code development.


Since its inception, OSEHRA and its community have had many accomplishments.  As a community effort, a code certification process was built and tested, leading VA to adopt a certification process that is focused on the usability of open source code.  OSEHRA has become a Standards Development Organization (SDO) accredited by American National Standard Institute (ANSI) to elevate the open source certification process as a national standard. A code base for open source VistA has been built, and certified code can now be sent to the repository. Additionally, a number of externally developed applications and modifications have been accepted and certified.

OSEHRA has been working under contract to VA since February 2016 to identify open source products that meet VA’s requirements and to certify them for VA code intake.  OSEHRA has recommended a number of high priority candidates to be taken in by VA, and those recommendations are under review by VA.  VA interacts with the OSEHRA Community on a consultative basis on a number of strategic issues such as licensing, cybersecurity, eHMP, and VistA Evolution.  This relationship has proven highly useful for VA leadership.

One of the major VistA modernization projects is the enterprise Health Management Platform, (eHMP). There are a number of important attributes in eHMP that reflect deep expertise of VistA and its deficiencies; at the same time, the open source operation was imbedded into the project from the start, rather than an afterthought. As a result, eHMP will bring about new user experiences and will allow easier participation of the open source community. The code was released as open source under the Apache License Version 2.0, and community engagement was simplified by offering many standard programing tools.  While the earlier version of VistA was a huge gain for the private sector, the advances in the private sector did not result in advantages for VA, largely because there was not a functioning open organization and community with a shared vision. The code forked thousands of different ways, making code sharing very difficult.  In order to build a high-functioning open source community around eHMP, VA is engaged with OSEHRA for licensing, community code management, and promotion of the code to the greater community.

We believe the new eHMP effort underway will maximize the open source expertise of VA and OSEHRA. The advancement of eHMP is an excellent example of how VA can future-proof its endeavors while developing the best, lowest cost IT solutions for the Veterans.  This is the most sustainable approach, and should be replicated.  VA’s investments in open source as part of a modernization program will allow for more accelerated improvements towards an open digital health platform.  VA’s journey into open source is picking up momentum, and as its policies and infrastructure mature, the cultural change will prevail.

We view the ODHP as a continuum of VA’s long history of innovations: DHCP, VistA, FOIA VistA, open source, eHMP and ODHP. Although the journey has not always been smooth, we believe that lessons learned from the past are providing the necessary guidance for VA to reclaim its preeminent position as offering the best IT solution for Veterans and the Nation.

2.2 Fostering an Open Ecosystem

An open source ecosystem consists of three components: software, community, and governance.  OSEHRA has fostered such an ecosystem by building powerful tools to manage software, developing and managing a community of experts, and establishing governance to facilitate efficient collaboration among community members around the globe.
 
An open source ecosystem is more than just free software. As shown in the diagram at left, the ecosystem’s three components have to work harmoniously and seamlessly.  Activities of these components are described later in this document to highlight their role in various aspects of open source operations.

In 2015, IBM commissioned an Innovation Series Report entitled Making Open Innovation Ecosystems Work: Case Studies in Healthcare. This scholarly report in part examines VA’s effort in building a “new ecosystem around its VistA in order to better facilitate the flow of innovations practices and processes between the VA and external agencies and private firms.” The authors argued, “government agencies can increase the benefits from their open innovation efforts through the use of sponsored participation in technology ecosystems.”

Managing such a community in an ecosystem where a Federal agency has a dominant role creates significant challenges.  Many of the rules and regulations seem rather unfriendly toward openness. Often, culturally, the openness is seen more of risk and burden to the individuals within the agency.  The IBM report contained the following statement:

There is also some concern among the non-VA members that the VA still holds much of the power in the ecosystem due to the size of both its resource contributions and its specific software needs. The prevailing concern would be that, if there is a conflict between the VA and some other member of the ecosystem, the VA’s needs would be granted primacy over smaller vendors’ needs. To combat this effort, OSEHRA has attempted to make all decisions transparent and open to the entire ecosystem, to allow everyone to see how any such decisions are made. OSEHRA is also attempting to ensure that the other members have an equal opportunity to join the various working groups and committees to avoid any undue influence by any single member, including the VA.

Since the publication of the report, much progress has been made in some aspects of open source operations; however, universal improvements are yet to be made.

2.3 Future-Proofing the VA Platform

The stated objective of this proposed project is to create a “Next Generation Digital Health Platform that is integrated, future-proof and optimizes the cost of operations.”  This section will focus on the concept of a “future-proof” system.  As the nation’s largest healthcare provider, VA is challenged to keep pace not only with emerging technology, but also with evolving clinical practice. The question then becomes how to future-proof major component applications and maintain them cost effectively.  Open source is a major part of the answer.

Open source methods have gained tremendous momentum in recent years.  Many enterprises are adopting open source processes and are integrating open source software into their products.  Business cases for open source vary.  For example, Airbus adopted open source in response to the requirement to support the deployment of aircraft for up to 75 years.  They recognized the risks of attempting this solely with in-house expertise.  The solution was to “future-proof” their software by creating a worldwide open source community around the software, with engineering expertise inside and outside of Airbus.  That provides a much greater support base than they could ever have achieved internally.

According to Pedro Alves, Senior Vice President of Pentaho (a leading IT corporation):

Although we can’t predict the future, we can be prepared to adapt. A global IT architecture touches a lot of different areas and departments, each with their own requirements, constraints and goals. I’m a huge fan of picking the best tool for the job; what works very well for one job, may not work for another. Crucially, even if it’s the best tool today, it might not be down the road. So in my opinion, the best way to future-proof an IT architecture is to treat each individual component as a service provider, abstracting the technology itself and focusing instead on what it’s doing. If at any point it makes sense to swap the technology, all we need to do is make sure that the same service continues.

This is where open source comes into its own. Compared to proprietary tools, open source software is interoperable by design. It comes with the ability to plug into any type of information source today or in the future, offering the best insurance policy against changes in the dynamic and unpredictable world of IT.

This analysis is very relevant to healthcare-related IT at VA, so we offer some further suggestions.  VA should put architectural guidelines in place that require all development of digital services to be compliant with the emerging open standards that will drive interoperability in the healthcare community.  VA should look to organizations like HSPC, who are currently seeking to emerge such standards into broad community acceptance, and to standards like FHIR.  The value of any community mechanism of sharing, interoperability, or communicating, is exponential to the number of nodes in that mechanism.  This makes the selection of standards and architectural axioms a critical forecasting endeavor, in that selecting such standards that will in fact eventually dominate the environment is essential.  To select standards not adopted by the broader community can stovepipe the organization’s platforms and greatly reduce the value of the selected mechanisms.

The healthcare community has not yet fully embraced a set of such standards, although some are starting to emerge.  Leadership in this area is needed to help this emergence and the eventual universal acceptance that will bring the real value to the healthcare community.  As perhaps the largest single entity in the healthcare community, VA can be that leader.  In selecting standards and architectural axioms, VA should strongly consider what will be inclusive of the private sector primarily proprietary EHR climate as much as DOD and other governmental healthcare entities.

Continuing to pursue Service Oriented Architecture (SOA)-driven development of new EHR components should move beyond the current, relatively optional architectural guidelines, to more of a hard requirement. Modularity in constructing everything should be a mainstay of this policy, and hard coding enhancements and new clinical support capabilities into existing VistA Mumps executable should be avoided as much as possible.  One current example of a successful SOA strategy is VistA.js, a SOA service that enables federation of data from all VA VistA instances for use by any consuming application that wants to utilize that service.  In pilot operation at 5 VA VistA locations now, with national rollout in FY17 Q1 and Q2, this middleware (released as open source under the Apache License 2.0) represents the kind of open approach that enables greater likelihood of community contribution as the components are more manageable in this architecture, and it supports the transportability, extensibility, and scalability that comprise much of the future-proof concept.

2.3.1 Making Open Source Work – Beyond Policy

The recently released Federal Government policy on open source is a major step toward institutionalization of open source software.  While the initial target for release is nominally “at least 20 percent of new custom-developed code” of the code base, it is easy to envision a future in which government software (unless classified for defense or other security reasons) is open source by default.  VA has in fact been a leader in the release of open source software to the community, using the Freedom of Information Act as a vehicle for releasing much of VistA and other applications to the community.  What has been missing is the potential benefit to VA and the Veterans from participating in open source.

The concept of open source software goes beyond “giving away” source code.  The full realization of the potential of open source software happens when ideas and improvements are returned to the originator by individuals or organizations that have tested and utilized the released code.  To date, VA has not progressed beyond the simple release of code, and thus has foregone the cost savings and accelerated innovation offered by “real” open source operations.  Red Hat is an excellent example of the potential.  Their use of Fedora as a fast-cycle platform to capture community improvements and bug fixes gives them a cost-effective force multiplier for their development and maintenance activities.  

After evaluating the latest code submissions in the Fedora environment, Red Hat is able to bring the best of the innovations into its Enterprise Linux code base.  Red Hat future-proofs its code by integrating the worldwide community into its development and maintenance processes.  VA could and should do the same.  OSEHRA was created for that purpose, but has never been fully utilized.  VA needs to expand its open source leadership and go beyond the minimum requirements of the new Federal policy – it needs to actively enlist the open source community in the development and maintenance process.

2.3.2 OS within VA – Successes and Challenges

VA established OSEHRA in 2011 to ramp up its open source commitment by establishing an outside custodial agent for its open source code.  The past five years have seen steady incremental progress in community engagement and code availability, including “code-in-flight” releases of code still under development.  Perhaps the most important accomplishment was the first truly collaborative development program, led by the Immunizations Work Group.  More recently, the eHMP program has provided multiple code-in-flight releases to the community, and has set an example for future contractor-developed code by licensing their software under the Apache License, Version 2.0.  Output from VA code releases is a part of thousands of external electronic health record implementations, including a national implementation by the Hashemite Kingdom of Jordan.

What VA has not done successfully is take in code from the community.  To date, the most visible intake program is the adoption of Fileman 22.2, a major upgrade to the core of the VistA EHR.  However, it took a major contract effort to condition the code for intake, and the community was unable to participate in that process.  As a result, a delta was created between the version submitted by the community and the version ultimately adopted by VA.  That delta will have to be addressed, or the code will be permanently “forked,” making it more difficult to collaborate downstream.  While many smaller enhancements and corrections have been available to VA, none have been successfully adopted.  This lack of ability to incorporate external code (even the output of VA’s own funded innovation projects) results from multiple cultural and business process issues, and it is the single most important impediment to future-proofing VA’s application systems.

The challenge for VA is to create the conditions necessary to conduct development transparently outside the VA firewall and to leverage the power of community collaboration.  If this challenge is met within the context of the open architecture and open standards environment described below, VA will emerge with a powerful, sustainable digital platform.

2.4 Software, Architecture, and Infrastructure

Open architecture, particularly as envisioned by the Health Services Platform Consortium (HSPC), has the capacity to facilitate secure and reliable data exchanges using modern RESTful interface capabilities. Wherever possible, the Fast Health Information Resource (FHIR) standard, toward which vendors and public and private enterprises are moving rapidly, should be considered for delivering these capabilities.

Systems, architectures, and interfaces should all be developed and deployed with steady and prominent awareness of the workflows they are to implement. As demonstrated from the outset of DHCP / VistA development, workflow support can be sustained through Agile processes that pair information technologists and clinicians in a tight feedback loop that continues through the design, analysis, development, and implementation process. By contrast, the later introduction of steadily increasing numbers of contracting, purchasing, and management layers into the systems development process has stretched, and often completely severed, this vital feedback loop. The result has been chronic deployment failure, diminution of the quality of care, and needless risk to Veterans’ life and health.

Successful implementation of information-exchange standards within an open-systems architecture faces two challenges. The first is the ability of vendor systems, particularly proprietary technologies, to conform to the best-practice workflow profiles developed by industry. DICOM and IHE have successfully addressed this challenge by facilitating vendors’ cooperation in building standards and profiles, thus achieving vital buy-in at the core of the system development process.

The second, broader challenge to information processing and exchange is an awareness of the need to accommodate as many workflow variants as may reasonably be expected in clinical practice. Usable systems provide clinicians the ability to “break the glass,” allowing out-of-sequence or out-of-range actions to be undertaken at the point of need with full audit and accountability. Better still are efforts being discussed at such venues as HSPC to model flexible workflows into new and existing systems, diminishing the need for “glass-breaking” by capturing workflows as they unfold in real time. Undertaken in an open-architecture, open-standards environment, such flexible workflows have the capacity to produce a visibly learning health system within the span of the current generation of development efforts.

2.5 Public-Private Partnership Models

The goals stated in this RFI cannot be achieved by VA in isolation, but rather must be sought in concert with the broader community.  Inclusiveness of community input is only a portion of what is needed, as community buy-in to the answers is more important. Seeking instances of private-to-public system interaction to create successful examples of the use of these emerging standards, and demonstrating as well as quantifying the value returned from this approach, will be the keystone in gathering momentum of broad community acceptance.

The Open Digital Health Platform will be an evolving concept that cannot be codified in a handful of task orders. VA needs to have a substantial and flexible mean to engage the community. Task specific contracting mechanisms have been a challenge for VA to engage open source community for the propose of innovative solutions and ideas where the process of collection lessons learned from engaging with the non-federal entity over a period of time, in turn, helps inform public policy.

VA should engage open source community through a cooperative agreement where substantial VA involvement is expected. A cooperative agreement would allow VA to enter into agreements and/or partnerships on an “as needed” basis to solve fundamental problems facing Veterans and their families. Cooperative agreements provide the flexibility that the Secretary of Veterans Affairs needs to test innovative ideas to solve emerging issues/problems, evaluate results, and scale up successful outcomes across the enterprise. In the case of open source community engagement, the outcome of an effort is inherently difficult to define, where the process itself bears information needed to more clearly understand outcomes.   A cooperative agreement will provide VA with the flexibility needed to respond to emerging opportunities on the horizon that, if leveraged, could improve the wellbeing of Veterans and their families.

2.5.1 The Potential of Collaborative Development

This section highlights key OSEHRA activities to facilitate collaborative development within the VistA community. While specific terminologies and products may not directly apply to ODHP, the principles, processes and lessons learned will be highly relevant to make ODHP a lasting success.

To facilitate collaborative development, OSEHRA has taken on two complementary product efforts. The first effort, OSEHRA Forum™, provides an automated patch stream for open source VistA, making the product more easily maintainable by eliminating the need for solution providers and implementers to search for patches on the VA’s FOIA website. The second product, OSEHRA VistA Core™, defines and delivers a common set of key open source EHR functionalities.  Prioritization of these efforts was deliberate. Only with a workable maintenance process could it be expected to achieve wide adoption of OSEHRA VistA while mitigating the risk of additional code forking.

Build-out of OSEHRA Forum began in 2014 by a contract team based in Seattle, Washington, and continued through 2015. OSEHRA Forum achieved Level 3 OSEHRA Open Source Software Quality Certification™, the second-highest level available, in August 2015.

In November 2014, a three-day face-to-face meeting of 25 national software developers, architects, vendors, and clinical subject matter experts was convened in Oakland, California, to define the first phase of OSEHRA VistA Core. Elements to be aligned from among various distributions and included in the core were enumerated. These included database management tools, XML utilities, unit testing tools, and a number of bug fixes not addressed by VA. The group agreed upon a series of agile sprints.

The most important element to be aligned was the VistA database tool suite, File Manager (known more familiarly to the VistA community as Fileman). Fileman alignment presented a special challenge. Open source Fileman code licensed under the restrictive GNU Public License had been improperly submitted to OSEHRA’s repository as code permissively licensed under the Apache 2.0 license. When the original code licensor, Medsphere Systems Corporation (MSC), discovered the discrepancy, an agreement had to be reached under which the submission was publicly attributed (as MSC Fileman 22.2) and properly licensed under Apache 2.0, with special promotional consideration given for the contribution. A trilateral agreement was reached between MSC, the original submitter, and OSEHRA that allowed code alignment to proceed.

Fileman alignment was exigent because VA had already initiated a project for gap analysis of the Fileman code from OSEHRA against VA’s own 18-year-old legacy version and had expected the licensing to be settled. To minimize impact to VA’s project timeline, OSEHRA undertook an intensive one-month surge from early December 2014 through early January 2015 (including weekends and holidays), employing contract programmers to align MSC’s latest code with the changes that had previously been submitted to the OSEHRA repository. During the last week of this effort, each code artifact was inspected for proper attribution and licensing, and functional tests were conducted on 80% of the code base to verify that no existing functionality had been impeded.

Properly licensed, aligned, and fully functional code was delivered to VA’s project manager on January 5, 2015, enabling VA’s code intake evaluation to proceed on schedule. Intensive testing by VA and by OSEHRA community members including DSS, Inc., validated the updated functionality, allowing Fileman 22.2 to be deployed across the VA enterprise and released to the OSEHRA community in July 2016.

However, the contracting arrangement that VA had reached for the Fileman upgrade made it impossible for OSEHRA to collaborate with VA on resolving the resultant new divergences during the Fileman 22.2 deployment process. Post-deployment, efforts have continued to work with VA on realignment of functionality and on collaborative unit testing. Efforts are underway to make the process more open and collaborative. We have provided this example to highlight that adoption of a policy is not sufficient to make the policy operational.  It remains for VA to set actionable objectives and to devote resources to a collaboration that can only enhance the usability and relevance of what is arguably the world’s most powerful open Digital Health Platform.

2.6 Extending Services and Capabilities into the Community

How can VA then leverage its activities to “extend into communities through the United States?” VA has been a leader in this space, as VistA code has been released as public domain code to the community for many years. This code base has laid the foundation for businesses and clinical operations for many organizations worldwide.  The difficulty has been the lack of community engagement.

An open source framework offers the best proven means to collaborate, share, and innovate. OSEHRA has built such an open innovation ecosystem consisting of code management, community management, and governance.  VA has greatly contributed to the institutionalization of the open source operation, but there remain many additional challenges.

OSEHRA was established as an independent, nonprofit organization and chartered specifically to develop and manage a community that can participate in collaborative ventures. It serves the OSEHRA Community members through common and shared goals. It functions as an authoritative and unbiased organization and such business practice is essential in making the operation of the open ecosystem successful.

The following are some of the key attributes for successful open source collaborations that all members of the community should follow:

  • Open Meeting: All may participate in the standards development process
  • Consensus: All interests are discussed and agreement found, no domination
  • Open World: Same standard for the same capability, worldwide
  • Open Change: All changes to existing standards are presented and agreed upon
  • Open Documents: Making documentation available
  • Open Interface: Enables compatibility, backward and forward
  • Open Use: Assurances that users are required to use an implementation
  • Ongoing Support: Standards should be supported for the users

As a Federal agency, VA certainly has certain constraints.  Nevertheless, we have learned there are proper mechanisms to honor VA integrity and security requirements without forgoing open collaboration.  The major impediments to collaboration seem to be self-imposed by a cultural reluctance within portions of VA to engage non-traditional partners, and a contracting process that is unable to provide a workable framework for community involvement.

VA should be an active member of the community so they can organically engage the greater community that will sustain the technology and offer future-proof pathways. It is critical that VA be involved without dominating the community as domination will stifle the community and lead to alienation.  VA should not view the community as a contractor who is to be tasked to do certain things. Rather, the community is a team of members who are willing to share and collaborate for the good of the community assets.

3 Summary and Recommendations

VA has a long tradition of innovation in health IT, evidenced by its recent launch of an open source program to accelerate the rate of health IT innovation.  Numerous business processes within VA have been modified to allow open interaction of code and ideas with the community. The resulting successes are strong indicators that a Federal agency can indeed benefit from open source operations by working with an open source community. 

We are very encouraged to see that throughout this ODHP RFI, VA is continuing its commitment toward openness in source code, standards, architecture, and above all--collaboration. We are further encouraged that the concept of openness is seen as an enabling methodology for the success of ODHP.

OSEHRA and VA labored the past five years to achieve a fully operational open source concept. From that emerged a powerful base upon which more efficient operations can be built.  Our collective open source experience is different from other activities in the private sector.  This is open source as a public-private partnership in which the public sector, VA, has many real and perceived constraints in opening the business process and changing the culture. The open source operation with VA is operational, but the efficiency is low. This should be improved, and we have some recommendations for all members of the community on how to best improve the efficiency of open source operations.


  • Most importantly, trying to insert certain aspects of open source into existing government’s legacy processes does not work. Instead, the government processes should be reformed into open source framework and processes.  These processes must be integrated into all phases of software design, development, testing, sharing, improvement and reuse.  Open source deals with entire lifecycle of software management, not just an aspect here or there.

  • Programs should be developed in such a way that redaction is not necessary. Redaction often breaks the code, and then the code is often not easily repairable in the community. This results in perpetual forking and poor efficiency in code management and reuse.  Further, the idea of redaction, as stated in the current Federal policy, is already outdated.  VA’s own coding standards provide guidance to ensure that sensitive information is not included in source code, but rather set up via variables that can be initialized inside VA for production use.

  • Third, code management needs an updated infrastructure. The common community code should reside in the open source community from the beginning. Code can then be drawn from the community repository and the end user (VA in this case) can add specific functionalities while preserving the community code.  Any modifications made to the base code should be contributed back to the community and be reviewed for inclusion to the base code. This is the business model of Red Hat’s previously described success, and it should be widely adopted to ensure other successful open source operations. 

  • Fourth, Open Source Certification should be applied to ODHP and all future VA IT activities.  This certification has been tested and has become a routine operation in current activities, especially documentation, intellectual property and open source licensing, testing, and software standards and conventions. VA had a leadership role in developing this certification to improve usability, as not all open source software has the documentation, unit tests, and peer review results necessary to be easily used.

  • Finally, VA must have a disciplined process of managing its portion of the system while supporting the community that will help to future-proof the technology. The ODHP will have VA-specific parts as well as parts that are common with the participating collaborators.  Additionally, the private sector will add its own discriminating innovations for their use. Together, common innovations will emerge and these will enhance the common core, thus sharing the development cost.  It is necessary to remember that adoption of open source does not relieve the product management responsibility of the end user. Open source operations are designed to support flexibility, but they also require clear definitions.  Clarity and collaboration is essential to nurture a community-based core that can grow and sustain itself-- a benefit to all members of the community. 


This OSEHRA Community has the collective experience to provide a high-performing base from which the Open Digital Health Platform can emerge and flourish.  VA has not received sufficient credit for its VA’s successful launch of open source and its continued efforts.  Yet, the OSEHRA Community has a better understanding of remaining challenges and the specific expertise through which to resolve them.  Open source should not be an afterthought, and the OSEHRA Community will ensure that it remains a priority and an asset for VA.