MOHIE Planning

I'm headed to Jefferson City, to attend Missouri's HIE Planning Technical Architecture Committee tomorrow. This is an exciting chance to change healthcare in Missouri.

However, I'm worried that the group will be filled with lobbyists and vendors trying to get their piece of the pie. I would rather build something and give it away to Missouri and any other state which wants it. I think its time for an inclusive, open source HIE, based upon NHIN CONNECT.

Wish me luck

Connect 2.2

NHIN Connect 2.2 was released recently. Major changes from 2.1 include:
* BPEL removed, yay!
* Secure communication extended to Adapter

Testing it, I have found

* Build is much faster
* Execution of Self tests is faster (though not yet fast)
* Memory usage is still high

Ahead for 2.3, we are working on platform independence. Linux build soon?

How NHIN Connect Ant Scripts Work

global build.xml task default
- depends on build
global build.xml task build
- calls do-to-projects(do-to-target => build)
global build.xml task do-to-projects
- parses xml file build.projects.xml
- for each /projects/project
- determines project directory by directory element
- invokes ant on project's build.xml for target build (or whatever do-to-target is set to)

project build.xml task build
- sets property target-to-call to jar
- calls call-target-in-isolation-if-out-of-date

build.lib.xml task call-target-in-isolation-if-out-of-date (imported from project)
- Creates xml file named temp.xml
- writes ant script to temp.xml
- invokes ant on temp.xml target temp

temp.xml target temp
- sets property project-to-build to .
- preserves property target-to-call
- sets property base to ./lib
- imports property file ./lib/nblibraries.properties
- imports property file ./nbproject/project.properties
- calls build-project-if-out-of-date

build.lib.xml target build-project-if-out-of-date
- Checks classpath
- If need to build, invokes ant on project's build.xml target jar (or target-to-call)

project's build-impl.xml target jar
- depends on compile

project's build-impl.xml target compile
- depends on -do-compile

project's build-impl.xml target -do-compile

Connect Code-A-Thon Photos

Add your Code-a-thon photos to flickr with tag of nhinc

Building the Connect Community

On August 27th, I attended the Connect Code-a-Thon in Washington D.C. Connect is an project originally designed to hook up 20 federal agencies to the NHIN, or National Health Information Network. The leadership recognized it had much broader applications, and so released the sources to the public earlier this year.

Like our other open-source products, my company, Object Computing, Inc. has been investing in Connect for a while now, building testing, providing feedback to the team and helping others in the community do the same. We were excited to hear about Code-a-Thon, but were lucky to get in. The 100 seats filled up fast.

One thing which happens frequently in open source products is a broadening of the solution to a larger problem set. Connect was fitting this model. While looking at the sources I realized it was currently tied to a specific directory. In this case it was C:\Projects\NHINC. Other paths were assumed as well. I found this to be unusable for the community, I proposed a project, called Path Neutrality, to allow the code to be checked out anywhere, deployed anywhere, tested anywhere. I posted my idea to the Connect forums and asked for those interested to respond.

I waited to hear from the community, but did not get a reply. The community manager, Brian Behlendorf, replied promptly that it was a well-written project and it made technical sense. Yet, the community was strangely silent as Code-a-Thon approached.

Another announcement about Code-a-Thon indicated there would be 10 tables - one for each of the project areas - including one for Path Neutrality. This was great support, but I still worried how embarrassing it would be to sit alone at that table. Still, the acceptance of this project, even into the agenda of the event, made me know, that community was important to the Connect team.

The day arrived, and I entered the Hubert H. Humphrey Health and Human Services Building which I called H5SB, met some of the staff and a few developers. I tried selling another developer who was interested in a Linux version on the idea of Path Neutrality. We found the table, and there were already two other people there. What a relief.

The event started and Brian introduced the topics at the various tables and asked people to indicate their interest. I was stunned that the table was, in fact popular. Path Neutrality, naturally, was critical to getting Connect running on Linux, and the Linux contingent had arrived. Also included at the Path Neutrality table were discussions on containers neutrality, database neutrality, and even EJB-independence. The Social Security Administration, who used Connect on Solaris, showed a lot of interest, as did Connect's Chief Architect.

We worked on some of the key issues surrounding path-neutrality and prototyped some possible solutions. Jason from the development team joined us for most of the day. There was a real sense of a can-do attitude in the community. It was great to be part of these passionate developers wanting to broaden the application of this product.

With all the buzz around our table, a reporter from GovHealthIT stopped by and we spoke for a while, and she wrote up the project in an article.

If you have an interest in helping out, check out the Connect project. This community is a very welcoming one. If you have Java web services experience or health IT domain knowledge, this open source project can use your help. Release 2.2 is coming soon, and quarterly Code-a-Thons are planned. California, Atlanta, and St. Louis are possible future sites. I hope I have the time to help keep momentum of Path Neutrality going.

Saving Money In Healthcare

There is a lot of talk today about healthcare reform and how we can save so much money, and all the waste in it.

A few points on this topic -

From the outside, there appears to be no focus on cost containment in the healthcare industry. When I drive by my local hospitals I always see construction. The same goes for another growing-faster-than-inflation money hole, the local university. And why not, the demand for healthcare has been inelastic. As the price they charge goes up, their business does not see an equal percentage drop.

If costs are to be reduced, it first means a loss of jobs - fewer direct employees in healthcare. Less doctors, nurses, admin staff. It means less investment - fewer indirect employees in healthcare. This is a sad, but true reality. People you know will loose their jobs.

One way to achieve cost reduction with less of a jobs impact may be to end hospital competition. In a capitalist society, competition generally reduces profit and means lower consumer prices. In this industry, I think the opposite is true. If cost containment is the most important aspect we'd like to change in healthcare, we would stop the healtcare arms race and instead encourage hospital systems to work together.

For example, Hospital A would focus on cancer, B would take trauma, C heart conditions and so on. With these agreements in place the hospitals would then outsource their other needs to each other, and invest heavily in their own specialty. This would insure the care you receive would be served by truly the best doctors with the best equipment in the region. Today, you wonder if your doctor is competent and if the hospital across the street has better technology.

This of course is against the law. Our antitrust laws make this illegal, and an exception would have to be made for healthcare. The risk is that as the only game in town, Hospital A can then charge through the roof for their cancer service. As part of the agreement, we get regulated prices, much like we do from public utilities.

I think its crazy enough to work.