David Riley is president of Alembic Foundation.
Give me some background about yourself and about what Alembic Foundation does.
I’ve been in healthcare since 1976. I started out in nursing, and then eventually moved from nursing to medical training and became a primary care physician assistant in the Air Force in the early 90s. I went to med school to finish that out and then practiced primary care medicine in one of the Air Force clinics in Los Angeles for a couple of years.
Then they moved me to the Pentagon and got me involved in health information technology. I was brought there to specifically get electronic health record stuff off the ground for DoD. Spent a couple of years putting that acquisition together. In the first year of development, I was involved as an independent consultant after I left the military to get that rolling.
Subsequent to that, I stayed in health IT and informatics consulting and was brought to HHS in 2007. That was when we were starting up the NHIN, the Nationwide Health Information Network trial implementation. They put out an RFP on the day that I was brought in to organize the federal agency so that they could come up with a strategy for how they would be involved in the trial implementations and the go-forward strategy for doing an implementation of the standards and going into operations.
That’s when Vanessa Manchester was brought into the picture as my program manager. We stood up the CONNECT project as a part of that activity. We managed the CONNECT project for about two and a half years through the life of that contract and prepared the statements of work for the re-competition for that.
We disengaged from ONC in November. When we started the CONNECT project as a software development project, we didn’t see a future where ONC would continually be involved in software development. It would eventually be rolled out to an open source community that would pick it up.
We did one year of development, released the software in 2009 as an open source, continued to develop it as the federal agencies were moving into production with it, and began to grow the community. By the end of September of last year, we had about 2,000 unique organizations that were either downloading it, using it, participating in Code-A-Thons, participating in training seminars, or just simply tracking it until their organization was ready for downloading and using the technology.
One of the things we were trying to do was to create an open community where the governance and the prioritization of features were a joint activity of the whole community. Up until then, the federal agency set the priorities. They were funding it, so they set the priorities, but we didn’t have a full open process where community members could participate in decision-making to the degree that you would normally see in an open source community. It wasn’t that the federal partners didn’t want that — they did want that — but they were just trying to figure out how to make the transition without causing problems from an operational perspective.
We had brought in Brian Behlendorf in late spring, May or June of 2009, as a consultant to help us figure out a strategy for building this open community and rolling it out to an open source community. We started the undertaking of a series of steps — they were small incremental steps. First, we made the tracker system available so people could report bugs and enhancements and make change requests from the community. Then we started opening up the development process and making it the backlog available so people could review that. The last step was transitioning it out to another organization from FHA [Federal Health Architecture] to a non-profit that would be able to grow the community and foster that.
We had always hoped that perhaps somebody else would take on that job of doing that. But when the contract pickup hit in September on the re-compete, we realized that the community was in danger of diffusing all that energy that had been focused. We decided we would set up the foundation to do that.
Initially, we were thinking, “OK, we’ll take on the Aurion Project,” but we saw that there was this growing need among federal agencies to figure out how to engage open source communities. Not just simply to build software, but to actually build full up ecosystems where products and services would be developed around software projects, CONNECT being one.
I think we’re also seeing the same kind of desire with the VA’s current open source EHR RFP that’s on the street now. Bidding will close on that on May 20 with contract award set for June 22. What they’re specifically requesting there is a custodial agent that can take the VistA code and handle growing the community in the open ecosystem around that. It’s a very similar kind of need. We saw multiple instances across federal agencies where they needed custodial agent services.
When we set the Alembic Foundation as a 501(c)(3) non-profit organization, the IRS requires you to define your tax-exempt purposes. There’s eight different categories. We selected four tax-exempt purposes. Our primary charitable purpose is defined as being the caretaker of the commons. This is where all this idea of custodial agency comes in — the idea that we create a common infrastructure that’s shared in terms of investment and it’s publicly available under an open source license, and then folks can move up the stack and focus on end user experience on the edge, building functionality, spend their money to build the infrastructure they can focus on the unique things that are value-added to the consumer. That was the model that we were looking at in terms of this idea of a shared commons.
We also have an educational tax-exempt purpose, where we’re looking at this idea of setting up a summer institute of informatics, kind of like Google’s Summer of Code, but it’s not just simply writing code. It’s more in the line of informatics, which is more than just simply writing software.
We also have a tax-exempt purpose that’s focused on scientific and technical research and development for basic applied and operational informatics research.
The fourth area is literary publishing, so that we can publish materials and manuals and how-to guides and all that kind of stuff around this idea of the commons and the informatics research that we’re doing associated with the commons.
By focusing on transformation through disruptive innovation, using open communities and open processes in those communities to develop open technologies, this is how we plan to nurture and grow the commons. The CONNECT software in that community is the first instance of a community that we stood up with the purpose of continuing to evolve an open source product so that we grow the commons.
The idea now is that we can have full and open participation by government agencies and then private sector working together under a common governance structure, and then common ability to invest on both sides, either through contracts with the government or donations on the part of the private sector, or individuals or corporate sponsorships is one way of participating in that.
At this point there is no official relationship or financial backing from the government?
At this point for our end for Aurion, no, there is not. We brought the community over. We have a volunteer community for the Aurion 4.0 release that just occurred. We had 17 developers from five organizations that participated in implementing the software and building the software for this release. That’s a volunteer force.
What we would anticipate is that at some point down the line, federal agencies may or may not, depending on what their operational needs are, contract for specific features and functionalities. If the community process has set a priority and they have a priority that they think they need on a given time schedule, one way they can do that is either hire a contractor to do that and participate in the community, or they can hire the Foundation to do that.
So there are multiple ways that they can participate. One is contract directly for services. Another is to hire a contractor who builds that service, and then if they want to contribute it to the community, they can do that. Or, they can have government employees that are on staff direct their focus to participating in the community.
We have about 100 unique organizations that attended the Aurion Town Hall Meeting, which was a couple of weeks ago. We began to review the draft charter. The way we are set up, the non-profit board of directors basically governs the corporate structure. They delegate to communities their governance structures through a charter, so there’s a way to delegate the governance down to the community’s level for the operational governance of communities. By doing that, we separate out the fiduciary responsibilities to the corporate board.
It’s hard for government employees to serve on a private corporate board because it’s conflict of duties. What we’ve done is the things that would be conflict of duties are reserved to the corporate board, and everything else is delegated down to the community governance structure. Government people can participate as a governor on the board of governors of the community without having to worry about conflict of duties because of the way the duties are separated and split in terms of the corporate board versus the community board of governance. We did that intentionally so government folks can sit on the board of governors at the community level, whether it’s for Aurion or EHR or whatever projects that we happen to take on as we move forward into the future.
Just to refresh the memories of readers who may not be quite as familiar, describe in a couple of sentences what the CONNECT and Direct projects are and how they’re different, if you would.
CONNECT is focused on organizational health information exchange. This is where Organization A wants to send or receive personally identifiable health information from Organization B.
You’ve got these legal definitions that are involved. Usually whatever Organization A is, it may be multiple organizations, but they’re bound together because they either have contracts or agreements in place. And then, everything else is defined as “them,” so when they want to exchange information with “them,” whoever “them” ends up being, they needed an ability to do that.
That’s what the NHIN was about, was creating B2B interfaces — the business-to-business interfaces — for exchanging health information. That’s what CONNECT and subsequently Aurion is focused on.
Direct was really focused on provider-to-provider kinds of exchanges. It was like one step up above faxes, so the day Doctor A decides they need to send some information to Doctor B, they do business with them and they know their fax number and so they send it. The trust that’s there, there’s kind of an implied trust, because you’re somebody that I know and I refer patients to. There may not be formal, legal instruments of trust.
For example, at the business-to-business exchange that CONNECT usually is used at, organizations will sign a document like the Data Use and Reciprocal Support Agreement, or the DURSA, to be able to create the legal infrastructure for exchanging data. CONNECT is the technical infrastructure for the trust fabric.
Direct has an implied level of trust, because I know you, we do referrals. It’s a directed push of information, whereas up at the exchange level where CONNECT is applied or Aurion, you can push information, you can request and retrieve information, or you can publish and subscribe to information. We cover all three of those messaging paradigms in CONNECT, whereas in Direct right now, the message paradigm is push. They use secure SMTP for that transaction.
People assumed when you left the project that perhaps it was in trouble, but you’re saying the plan all along was to create an external group and the timing was right.
Well, yeah, the timing was kind of coincidental, I guess, with the contract’s hiccup. The plan was always to roll it out to some organization. We’d been looking at a number of different organizational models, like trade associations like 501(c)(6), and we’d even looked at Mozilla and Apache. Basically we were looking into different missions of these organizations to figure which if one of them could be a suitable home for the software and the community.
From a licensing perspective, it wasn’t a licensing issue. Any one of those organizations could have probably been a home for it. The issue was the community and whether they had knowledge about healthcare in particular and health information exchange specifically.
We had thought that we probably needed to set up an organization or work with somebody to get a new organization set up to do that. When the acquisition hiccup occurred, it really created an impetus to make sure it was done right away. Because of this interregnum where no development at all was planned to go on until the contract issues were resolved, we realized that there was an opportunity to go ahead with the plan of setting up the organization and just making it happen. The longer we waited, the more danger there was that the community would diffuse away and we would lose the forward momentum that we had.
We just decided that if it was going to be done, the timing was now and nobody else was willing to do it. We gave it a lot of thought and consideration and thought, “OK, we’ll go do that.” That makes for an interesting next step in terms of the work that we’ve been doing. In some ways, it was just kind of opportunistic. We were trying to figure out how to gracefully transition and because of that hiccup, it became more urgent to get something stood up. We just took advantage of the opportunity in the sense of, “OK, we’ll go do it and we’ll do it now.”
You mentioned the VA’s project to assign a custodial overseer of VistA. Is that something the Foundation will be bidding on?
Yes. We’re planning to be a part of a good team on that. The RFP is out and proposals will be due in on the 20th of May and then contract award is expected on the 22nd of June.
How do you see that playing out? It seems like it’s not really clear how much is going to be built and maintained through open source versus how much will be commercial off-the-shelf software.
The recent announcement about the preference for COTS is interesting. From an acquisition perspective in the FAR and the DFAR, open source software is viewed as the equivalent of a COTS product. From the acquisition perspective, they could adopt the use of open source technologies and solutions and still be compliant with that guideline that they said they would prefer COTS solutions first.
It didn’t mean that they would necessarily license proprietary code. It doesn’t explicitly say that they’ll have a preference for open source, but certainly what they’re looking for are what are called non-developmental items, NDIs — things that they’re not having to invest a lot of money in doing development on. Open source is one way to do that. Proprietary products, combinations of those two … all are ways of putting together acquisition solutions that the agencies can go with.
The pendulum swings back and forth between whether we buy something that’s already built in the government, or we whether we build something. It depends on when the last successful project was. If they did a big project where they were building software and it got behind schedule and they had feature bloats and they weren’t able to deliver on time and were going over budget, suddenly the pendulum swings for preferring COTS, going out and just buying something like a lab system from Cerner or something like that, or an EHR from Epic.
Then when they do go down that path and they end up with implementation costs and they overrun budget or schedule and they get bad press or if the Congress is jumping down their neck, then they swing back to the other direction. I’ve been watching this for almost 20 years, this pendulum swinging back and forth.
What we’re trying to do is figure out a path forward where we can create open innovation, not just simply open source, but also working with proprietary vendors to do what Henry Chesbrough characterizes as an open innovation process, where they engage their users and people that have licensed their products to help evolve the products through an open process, even though it’s retained under proprietary license.
In my view, the path forward is engage the open source community, engage the vendors in this open innovation process, so that in the end, what we’d like to see happen is this investment in the common infrastructure that everybody can use move up the stack where the proprietary vendors are building that value added on the edges focusing on the user experience.
In the EHR world, usability and acceptance by the user is the piece that prevents a lot of them from achieving the market penetration that they would like. It’s getting the user experience right. There’s so many doctors and so many ways that they do things that it’s hard to address that when you’re having to build the infrastructure and shoulder the cost of that in addition to building usable applications.
If we all contribute and build what’s equivalent to the Defense Highway System, then I can use that to move fruit and produce and you can use it to move apparel and somebody else can use it to move steel. We’re all using that same common infrastructure that we paid for, in the case of the Interstate system, through taxes. It supports a lot of business models because that common infrastructure is there.
What we’re looking for is, what is that infrastructure in health IT that could be the shared investment that, if we got it in place, that could really spark the innovation that we want in terms of this rich ecosystem of applications that really are focused on the end user experience? Thereby you gain greater penetration into the marketplace of providers using these applications because they have the kinds of apps available to them at a price that’s more affordable.
If everybody’s not having to shoulder the cost of the infrastructure component, you’re not talking about million-dollar systems. You could actually literally end up with an app store built on the common infrastructure where apps may be as low as a couple of dollars, a la the Apple app store model. Or they may be a little bit more expensive if you get something that’s a real sophisticated decision support application, but it still wouldn’t be millions of dollars or tens of thousands of dollars for these apps.
They would be much cheaper. Therefore, you would be more likely to achieve a greater market penetration, but you’d also have more uptake. You’re not having to sell 10 multi-million dollar systems. Your apps are available out there, the distribution channel is a lot cheaper, it doesn’t take as much to get to the marketplace. You have 800,000 people using this app, or maybe 100,000 using that app. Even though it’s a lot cheaper application, you can still make money at it in the proprietary world as well.
Any final thoughts?
It’s a big vision. There’s a lot of work to be done. We’re just going to bite it off a little bit every day and see where we end up and see how much good we can do.
Heard that all of our sites are moving to Epic. We have started hiring internally already. Don’t know if this…