Purpose
The is for internal consumption only. It does not go to VA. Still need to revise internal message as well.
We need to create a framework, for example using the Gartner’s report “Understanding the Impact of
‘Real World’ Open-Source ROI” as a starting point, where the VA can look into a given software
acquisition and determine:




White box versus black box
Software complexity – low, medium, high
Business opportunity – low, medium, high
Product maturity and governance - – low, medium, high
We can add other factors such as whether the software is infrastructure oriented or not.
The purpose of the framework is to help the acquisition process evaluate the open source factor. Even
under a “Open Source First” policy as specified in the GSA related post, not all software acquisition
should be open source if a proprietary solutions offer better value and the open source ROI is low. We
should articulate that as part of the operations concept and identify where in the reference architecture
proprietary software is fine, and where in the stack OSS is really a requirement.
Themes




Platform or Product
Context of Value
o Ecosystem versus Sub-optimized Subsystems
o TCO versus ROI
Community Driven Innovation
Open Adoption Model
Content
1.
2.
3.
4.
Problem Statement
Principles
Analysis
Recommendations
Problem Statement
In the typical government acquisition processes driven by business requirements, the value of open
source ROI is overlooked – it is difficult to calculate what that is when it comes to acquiring some
software. For example, we have often heard the statement from VA that the business requirements do
not say that the software to be developed needs to take consideration of working with open source
community to allow for bi-directional code intake. But if you don’t participate in the open source
community, you lose the value of the higher ROI that come with code innovation.
We also hear that the open source software need to be competitive in value or TCO when comparing
with proprietary solutions; however, TCO in isolation does not address whether it is a type of software
that can reap future ROI through mature open source community contributions that drive development.
Of course, bi-directional code intake is necessary for this as well. But it understanding the full value
requires taking into account new value and innovation as part of ROI and not just cost.
In addition to the bi-directional code intake necessary for a mature community to drive ROI, we need to
establish the context of value. OSEHRA as an ecosystem seeks to extend and preserve the value of
traditional M based VistA as part a larger open healthcare platform. There are other IT pieces that need
to be part of such a platform, and those pieces need to be consistent with an open architecture that
extends the reach of VistA to all stakeholders. An example of this is infrastructure oriented software
such as an ESB. In order for new modules to be easily tested and evaluated by the community, the open
healthcare platform core needs to be available to everyone and to have no barriers to entry. This points
towards open source IT infrastructure as an enabler for healthcare IT.
Principles
1.
2.
3.
4.
What is the context of value? VA or Healthcare Community
What are / should we measure? ROI or TCO?
Are we applying OSS to the Platform or to a Product?
What OSS business models are a fit for the VA and for the Community? Open Adoption
4.1. What structures encourage a Culture of Community?
Stable policy, long term commitment, follow-through, steady velocity, transparency,
clear and stable path to market for all stakeholders.
4.2. What structures discourage a Culture of Community?
Policy confusion, fragmenting the resources of the community, instability in the path
forward
4.3. What technical structures enable the community to collaborate efficiently?
Infrastructure-as-Code
5. Which elements of the Platform require an OSS model?
5.1. VistA is the core of the platform.
5.2. Other elements of the Platform seek to provide a pluggable infrastructure around VistA
to extend the reach of domain specific value in VistA by addressing IT concerns such as
scalability, security, and operations.
5.3. Both domain (VistA) and IT concerns must be addressed in an open manner by the
Platform in order to deliver a Solution.
5.4. OSEHRA provides a collaborative environment based on infrastructure-as-code
principles where the community can contribute to both VistA and the IT concerns of the
platform.
5.5. Components on the edge can be proprietary, e.g. a scheduling or even a lab system that
supports open standards for communication, assuming there is sufficient stability and
maturity in the Platform to provide modularity, and assuming that they are still publicly
available for testing and integration.
5.6. The platform core integration core that links modules together into a solution have to be
publicly available and stable so that Stakeholders have confidence that their investment
will be protected.
5.7. Different strategies for service enabling VistA are viable, e.g. EWD, VSA. These can be
managed by a Reference Architecture.
5.8. The platform core should have an OSS Reference Implementation to ensure that all
stakeholders have a path forward. Assuring broad participation provides the economies
of scale for both economics but also innovation.
5.9. None of this works if the principle stakeholder in OSEHRA, the VA, fragments adoption
by using proprietary infrastructure at the platform core.
Analysis
6. ROI Framework
7. Value Analysis
7.1. Standards and Standardization
7.2. Integration Enables Innovation
7.3. Community Driven Innovation
7.4. Accelerating Commoditization
7.4.1. How far has OSS commoditization curve moved up the technology stack?
7.4.2. How far has OSS commoditization moved up the healthcare stack?
8. TCO Analysis
8.1. Commercially Supported OSS
8.2. Cost of Access
8.3. Cost of Exit
8.4. Competition
8.5. Cost and Risk Sharing
8.5.1. OpenStack
VA Recommendations
Open Adoption Model



API Management
Infrastructure-as-code
OSS Reference Implementation
OSEHRA Recommendations
This is just a section that will not be in the whitepaper itself, but is a placeholder to remind us to extract
lessons learned and perhaps consider what we as a community can do to drive adoption and innovation
rather than wait for the VA. We currently are bottlenecked by the VA in terms of accepting community
contributions. What can we do to accelerate or change that? Is it a given that the VA should own this
process and be the rate controlling element?