The first PHR Patent Troll?

The following just came across my Google Alerts:Healthcare Analyst Values MMRGlobal Patents at $300-800 Million. This is scary. I’ve seen this company for years; they were one of the pack trying to build personal health records in the mid-2000s, and from what I’ve seen there is nothing in their historic offering that was particularly innovative – except that unlike most of the others running around at the time, they appear to have had some budget to file some patents, and they have now commenced shaking other people down.

Now, I haven’t done a very complete review of their patent holdings, and they may well have some highly innovative, original work there that took a substantial investment to develop and realize. But that’s not the trend, and I’m very concerned that this could be problematic for a lot of small innovators in the personal and clinical health records markets. Software patents have become a real problem across a variety of domains, but so far HIT seems to have avoided the worst of it. I suspect that this is in part because of industry’s long history – most of the core capabilities were introduced long enough ago that any patents would have expired. There’s a ton of prior art: you can track a lot of personal health monitoring to 1994′s Guardian Angel Manifesto. But that’s expensive to litigate when the trolls come out from under the bridge.

As it stands, I’m looking for defensive patent structures for my own start-up so that we have some chits to trade if someone comes knocking. And that’s a shame – I have better things to do with my time.

New Job, New Blog, Same Team

The last few months have been quiet on the blog for a couple of reasons. The biggest one is that I’ve been getting ready to leave my position at Children’s Hospital Boston, where for the last three years I’ve been Director of the Informatics Solutions Group. There were a couple of reasons for us to move on – the biggest being that the scope of interesting projects outside Children’s is so tremendous right now. And we’ve got a couple cooking, including one that’s not quite ready for a blog-announcement yet (but it will get there).

The other project is Beacon 16 Software, a new consultancy focused exclusively on design, development and implementation of advanced Healthcare Information Technology projects, along with several members of the ISG team who should be familiar from this blog. We’ve already done work for some of the major Boston hospitals, and this week – our first outside CHB – we’ve started a project to implement the remaining Meaningful Use functionality for a major hospital. We’re also working with startups to develop products and demonstrations in both clinical IT and life sciences. And I’m not above asking my blog readers for work – if you’re looking for a group that knows this industry up and down and has a great track record building cutting edge software, give us a call. We’re even remarkably affordable.

We have a new Blog on the Beacon 16 site as well. The focus will be Healthcare IT and software development. If you liked this one I think you’ll like that one. We’re re-running a few of this blog’s greatest hits, and the first new post is up now, talking about how to make product users into product champions.

I’ll also be keeping this blog going, although I’m going to pull the focus back a bit (probably no more posts on JSF and software engineering – we were getting our audiences mixed up). Instead I’ll be focusing on aspects of HIT development and healthcare policy that don’t belong on the Beacon 16 blog, and probably recount some stories of what it’s taking to build a small company. It may very well be interesting, so stick around.

Air Travel and Healthcare, Amended

The video below, “If Air Travel Worked Like Health Care” has been making the rounds of the healthcare blogosphere. I spotted it first over at Running a Hospital, and it’s based on Jeffrey Rauch’s column from the National Journal.

But wait, there’s more! After seeing the video, a physician friend pointed out that it was missing a critical point of disfunction. He then sent me this, which I begged him to allow me to post:

Booking Agent: Hello, NationalAir. How can I help you?

Customer: Yes, I’d like a flight from Boston to DC on February 3rd with Joseph Smith as the pilot.

Booking Agent: I’m sorry. Pilot Joe Smith is completely booked for the next 6 months. How about Pilot Jane Wallace?

Customer: I don’t know, my previous regional pilot recommended Pilot Joe Smith directly. Maybe you know my previous Pilot, Pilot Jeffery Jones? He and Pilot Smith trained together in Denver. Apparently, Pilot Smith is phenomenal on the Boston DC run. Be honest, is Jane Wallace a good pilot?

Booking Agent: Yes, Jane is great! She’s new to our airline, but she comes highly recommended. She graduated from the Air Force Academy with honors. She’s written several books on combat flight techniques and has studied passenger usage of air sick bags during high G evasive maneuvers induced by terrorist surface to air attacks.

Customer: Okay……great. What is her track record on the Boston to DC flight?

Booking Agent: I’m sorry, we don’t release that information.

Customer: Okay, how about stats of NationalAir flying from Boston to DC?

Booking Agent: We’re having discussions about that internally. I will tell you that 6 out of 10 NationalAir frequent fliers choose NationalAir when flying on the East Coast on Tuesday between 8pm-12am in December (p<.001). We also have great customer satisfaction for our inflight movie selection on transcontinental flights. That work was actually recently published in the International Journal of Travel Pilots. We also have more Air Force Academy trained pilots than any other airline on the East Coast. We're very proud of that.

Customer: Okay….that’s helpful. NationalAir certainly has a great reputation…I’m sure Pilot Wallace is more than capable of flying from Boston to DC. Book me for her please.

Booking Agent: Great, you won’t be disappointed. She has an opening in late April……

JSF Summit 2009 Review

I was fortunate enough to attend the No Fluff Just Stuff JSF Summit this week in Orlando Florida.  I entered with an open mind and left with a long list of technologies to evaluate.  As expected, I left with a greater understanding of CDI and JSF 2.0.  The presenters were  friendly and accessible and made a great effort to reach out to new users.  I had an opportunity to speak to all the presenters individually at the many breaks and social events.  They all listened to my perspective as well as the perspectives of the other attendees and seemed to genuinely respect our input.  I came in knowing no one and left meeting many new friends.  Like all NFJS presentations, the catering and accommodations was first rate.

The presenters included influential Java celebrities and presentation circuit veterans like Ed Burns, David Geary, Andy Schwartz, Kito Mann, and Dan Allen.  Arguably more interesting were the presentations for technologies from presenters you may not have heard of yet.  Stan Silvert, Cagatay Civici, and Lincoln Baxter III surprised many of us with excellent presentations on JSFSpy, PrimeFaces, and PrettyFaces.  Many other presentations got rave reviews, but I wasn’t able to attend all of them The overall theme was JSF 2.0 as well as components of JEE6 and JSF 1.2 technologies.  No technical conference would be complete without good speeches.  Dan Allen’s JEE6 keynote was energetic and genuinely inspiring and Jay Balunas’ closing speech on the virtues standardization was an enjoyable close to a wonderful conference.

For me, the technical highlights were CDI, JSF 2.0 standardized ajax, view parameters, view parameter templating and converters, composite components, and resource handling in JSF 2.  I’ll attempt to give the features the coverage they deserve in individual blog posts next year. The JEE6 release is more than exciting, it’s a game-changer.  The JCP has come up with the best JEE release yet and from what I’ve seen, they have a better stack than any competing technology on the market.  With modest promotion effort, they are likely to expand their marketshare beyond existing JSF users to new users from other frameworks and even win back a few frustrated Java users who defected to Ruby, PHP, and .NET.

I left the long conference both exhausted and full of hope for the future of the Java platform.

The specific sessions I attended were:

  • JSF 2: Keeping Progress Coming by Dan Allen and Andy Schwartz
  • EZComp: Composite Components in JSF 2.0 by Ed Burns
  • Polyglot JavaServer Faces by Kito Mann
  • Maturing your application’s security with Seam Security by Dan Allen
  • CDI (JSR-299), Weld and the future of Seam by Dan Allen
  • Killer Web apps with JSF 2.0: Ajax by David Geary
  • Upgrading to JSF 2 by Kito Mann
  • The Portlet Bridge and the 2.0s by Michael Freedman
  • JSF Component Behaviors Deep Dive by Andy Schwartz
  • PrettyFaces – Harness SEO, Improve User Experience, Ease Development by Lincoln Baxter III
  • Dumping JSF by Stan Silvert

Lincoln Baxter III deserves special mention for delivering the most entertaining session of the bunch.  He not only delivered a first rate presentation on his PrettyFaces project, but he rickrolled the audience and segued into a brief dance routine…all in the name of demonstrating the importance of RESTful URLs…something the Java community needs to take more seriously.

I left the conference very hopeful for the JEE platform and think 2010 will a great year for the Java platform.

Further Reading

Side Adventures in JSF 2.0: Deploy the Hello World example in Tomcat.

In a previous post. I showed how to do the absolute bare minimum to get a CDI/Weld project running in Jetty. Jetty is my favorite container because when launched from maven, it automatically redeploys classes as you modify them without configuring my IDE.

However, in every Java job I’ve ever held, the final product is deployed to another container, such as Tomcat. Fortunately, the Tomcat web application is almost identical to Jetty. Just take the identical application, add a context.xml and deploy.

Create context.xml

#from your project home directory (where pom.xml lives)
touch src/main/webapp/META-INF/context.xml
<?xml version="1.0" encoding="UTF-8"?>
<Context>
	<Manager pathname="" /> <!-- disables storage of sessions across restarts -->
	<Resource name="BeanManager" auth="Container" type="javax.enterprise.inject.spi.BeanManager" 
		factory="org.jboss.weld.resources.ManagerObjectFactory" />
	<!-- Uncomment to enable injection into Servlet -->
	<!-- <Listener className="org.jboss.weld.environment.tomcat.WeldLifecycleListener"/> -->
</Context>

Now, build the project using the standard Maven way:

mvn clean package

In your target directory, you’ll find a war you can deploy using tomcat manager.

Automate Tomcat Deployments using Cargo

If you’re like me, you hate doing things more than once when a script can do the job for you. Simply add:

<!-- Cargo - deploys to Tomcat using command 'mvn clean package cargo:redeploy'. -->
<plugin>
	<groupId>org.codehaus.cargo</groupId>
	<artifactId>cargo-maven2-plugin</artifactId>
	<configuration>
		<container>
			<containerId>tomcat6x</containerId>
			<type>remote</type>
		</container>
		<configuration>
			<type>runtime</type>
			<properties>
				<!-- Declare a tomcat.user and tomcat.password in your settings file -->
				<cargo.remote.username>${tomcat.username}</cargo.remote.username>
				<cargo.remote.password>${tomcat.password}</cargo.remote.password>
				<!--defaults to localhost:8080-->
				<!--<cargo.hostname>localhost</cargo.hostname>-->
				<!--<cargo.servlet.port>8080</cargo.servlet.port>-->
			</properties>
		</configuration>
	</configuration>
</plugin>

If you have a settings.xml file in your .m2 directory, then add the tomcat.username and tomcat.password variables. If you don’t have one, create a file named settings.xml in ~/.m2/

touch ~/.m2/settings.xml

If you have not yet declared a settings.xml, use the one below to get started and add your manager username and password.

settings.xml

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
	<profiles>
		<profile>
			<id>default</id>
			<properties>
				<tomcat.username>(a valid tomcat user in 'manager' role)</tomcat.username>
				<tomcat.password>(the manager password)</tomcat.password>
			</properties>
		</profile>
	</profiles>
	<activeProfiles>
		<activeProfile>default</activeProfile>
	</activeProfiles>
</settings>

Ready to deploy

Now you can deploy to localhost:8080 using the command below.

mvn clean package cargo:redeploy

The host and port can be configured by setting cargo.hostname and cargo.servlet.port.

All Done

Now you can deploy your application to tomcat automatically.

Further Reading

Adventures in JSF 2.0: Hello World Tutorial using Maven 2, JSF 2, Facelets 2, and Weld

In the first of many posts regarding the recently finalized JSF 2.0, I will be showing you what you need to do to write a simple Hello World Application. Instead of traditional JSF backing beans, this application will use Weld, an open-source implementation of JSR-299: Contexts and Dependency Injection for the Java EE platform. JSR-299 will be part of the upcoming JEE 6 specification.

Prerequisites:

Install Sun’s JDK 6, the latest version of Maven (presently 2.2.1), and the IDE of your choice.  I use Eclipse, but GEdit or notepad would work just fine. For this demo, I’ll be using Jetty, so you won’t need to install a container of any sort.

Getting Started:

Create Empty Project

Our first step is to create an ordinary empty WAR project in Maven using the

archetype:generate

command in the directory of your choice.

cd ~/workspace #this can obviously be anywhere.
mvn archetype:generate -DinteractiveMode=n -DarchetypeArtifactId=maven-archetype-webapp -Dversion=0.0.1-SNAPSHOT -DgroupId=org.bogus -DartifactId=jsf2_tutorial

Unfortunately, the default Maven archetype falls short of what we need, so we need to make a few extra directories.  We need a java directory and the test java and resources directory. I’ve also added the commands that an eclipse user would use to generate an importable eclipse project. Netbeans and IntellJ users can simply import the pom.xml.

#create a few extra directories for the project.
mkdir jsf2_tutorial/src/test jsf2_tutorial/src/test/java jsf2_tutorial/src/test/resources jsf2_tutorial/src/main/java
cd jsf2_tutorial
#if you're using *NIX, you can create empty files with this command.
mkdir src/main/java/org/ src/main/java/org/bogus/ #need to create package first.
touch pom.xml src/main/webapp/WEB-INF/web.xml src/main/webapp/WEB-INF/beans.xml src/main/java/org/bogus/HelloWorld.java src/main/webapp/index.xhtml src/test/resources/jetty-env.xml

Overview

I was very impressed that a simple Hello World project can be created with as little as five artifacts.

  1. /pom.xml
  2. /src/main/webapp/WEB-INF/web.xml
  3. /src/main/webapp/WEB-INF/beans.xml
  4. /src/main/java/org/bogus/HelloWorld.java
  5. /src/main/webapp/index.xhtml
  6. /src/test/resources/jetty-env.xml (for Jetty users).

Writing the actual Code

pom.xml

The first step is to the pom.xml file. Afterwards it can be easily imported into any modern IDE.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>org.bogus</groupId>
	<artifactId>helloworld</artifactId>
	<packaging>war</packaging>
	<version>0.0.1-SNAPSHOT</version>
	<name>JSF 2.0 Tutorial</name>
	<repositories>
		<!-- As of October 2009, a few of the weld dependencies were not yet on the main maven repo.  We can add JBoss repo as it is updated more frequently.  -->
		<repository>
			<id>repository.jboss.org</id>
			<name>JBoss Repository</name>
			<url>http://repository.jboss.org/maven2</url>
			<releases>
				<enabled>true</enabled>
			</releases>
			<snapshots>
				<enabled>false</enabled>
			</snapshots>
		</repository>
	</repositories>
	<dependencies>
		<!-- Common -->
		<dependency>
			<groupId>javax.enterprise</groupId>
			<artifactId>cdi-api</artifactId>
			<scope>provided</scope>
			<version>1.0-CR1</version>
		</dependency>
 
		<dependency>
			<groupId>javax.annotation</groupId>
			<artifactId>jsr250-api</artifactId>
			<version>1.0</version>
		</dependency>
 
		<dependency>
			<groupId>javax.faces</groupId>
			<artifactId>jsf-api</artifactId>
			<version>2.0.0-RC</version>
		</dependency>
 
		<!-- Jetty-specific scopes and artifacts -->
		<dependency>
			<groupId>javax.faces</groupId>
			<artifactId>jsf-impl</artifactId>
			<scope>runtime</scope>
			<version>2.0.0-RC</version>
		</dependency>
 
		<dependency>
			<groupId>javax.servlet</groupId>
			<artifactId>jstl</artifactId>
			<version>1.2</version>
			<scope>runtime</scope>
		</dependency>
 
		<dependency>
			<groupId>org.jboss.weld.servlet</groupId>
			<artifactId>weld-servlet</artifactId>
			<version>1.0.0-CR1</version>
			<scope>runtime</scope>
		</dependency>
 
		<dependency>
			<groupId>org.glassfish.web</groupId>
			<artifactId>el-impl</artifactId>
			<version>2.1.2-b04</version>
			<scope>runtime</scope>
			<exclusions>
				<exclusion>
					<groupId>javax.el</groupId>
					<artifactId>el-api</artifactId>
				</exclusion>
			</exclusions>
		</dependency>
	</dependencies>
	<build>
		<finalName>jsf2</finalName>
		<plugins>
			<!-- Compiler plugin enforces Java 1.6 -->
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<configuration>
					<source>1.6</source>
					<target>1.6</target>
				</configuration>
			</plugin>
 
			<!-- Eclipse plugin enforces download of source and JavaDoc jars -->
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-eclipse-plugin</artifactId>
				<configuration>
					<wtpversion>2.0</wtpversion>
					<downloadSources>true</downloadSources>
					<downloadJavadocs>true</downloadJavadocs>
				</configuration>
			</plugin>
			<!-- Embedded Jetty (jetty:run) -->
			<plugin>
				<groupId>org.mortbay.jetty</groupId>
				<artifactId>maven-jetty-plugin</artifactId>
				<configuration>
					<!-- force friendly name instead of artifact name + version -->
					<contextPath>${build.finalName}</contextPath>
					<!-- Where the BeanManager is constructed.  This is where we'll later declare datasource. -->
					<jettyEnvXml>${basedir}/src/test/resources/jetty-env.xml</jettyEnvXml>
					<!-- This parameter will auto-deploy modified classes...my personal favorite Jetty feature. -->
					<scanIntervalSeconds>3</scanIntervalSeconds>
				</configuration>
			</plugin>
		</plugins>
	</build>
</project>

Now that your pom is complete, you can import it into the IDE of your choice. Eclipse requires users to either install m2eclipse or run:

mvn eclipse:eclipse

Boilerplate

web.xml

Since JSF 1.2, the web.xml page got a lot smaller. This is where convention over configuration pays off. Also, faces-config.xml is now optional!

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5">
	<!-- Standard JSF 2.0 Configuration Paramters. -->
	<!-- No Joke!!...This is all you need now! -->
	<context-param>
		<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
		<param-value>.xhtml</param-value>
	</context-param>
	<servlet>
		<servlet-name>Faces Servlet</servlet-name>
		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>
	<servlet-mapping>
		<servlet-name>Faces Servlet</servlet-name>
		<url-pattern>*.jsf</url-pattern>
	</servlet-mapping>
 
	<!-- Weld Jetty Configuration parameters -->
	<listener>
		<listener-class>org.jboss.weld.environment.servlet.Listener</listener-class>
	</listener>
	<resource-env-ref>
		<description>Object factory for the CDI Bean Manager</description>
		<resource-env-ref-name>BeanManager</resource-env-ref-name>
		<resource-env-ref-type>javax.enterprise.inject.spi.BeanManager</resource-env-ref-type>
	</resource-env-ref>
</web-app>

beans.xml

In order to indicate to weld to initialize dependency injection, you’ll need to create an empty file named beans.xml. The mere presence of this file in your WEB-INF folder tells the container that your WEB-INF/classes folder is a bean deployment archive.

Application-Specific Code

HelloWorld.java

To confirm that Weld (A.K.A. JSR 299 or WebBeans) Dependency Injection works, we’re going to write an incredibly simple bean. In contrast to Spring, you don’t need to declare the package or bean. Simply adding the @Named annotations and declaring a scope is all that is needed to have your bean registered with the dependency injection container and visible to your facelets view pages.

package org.bogus;
 
import java.io.Serializable;
 
import javax.enterprise.context.SessionScoped;
import javax.inject.Named;
 
@Named //assigns this bean the name of "helloWorld"...its "de-caplitalized" class name
@SessionScoped  //creates one bean for each user session.
public class HelloWorld implements Serializable {
	private final String text = "Hello World!";
 
	public String getText() {
		return text;
	}
 
	private static final long serialVersionUID = 1L;
}

index.xhtml

Now we want to actually view the bean we created. Below is an incredibly simple xhtml/facelets page.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html">
<h:head>
	<title>JSF Demo</title>
</h:head>
<h:body>
	<h1>Does Weld Work?</h1>
	<!-- Your bean can be easily accessed via Expression Language -->
	<p>My weld-injected bean says: #{helloWorld.text}</p>
</h:body>
</html>

jetty-env.xml

Since we’re not using a full JEE container, we need to configure Jetty to prepare the BeanManager.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN"
   "http://jetty.mortbay.org/configure.dtd">
<Configure id="webAppCtx" class="org.mortbay.jetty.webapp.WebAppContext">
	<New id="appManager" class="org.mortbay.jetty.plus.naming.Resource">
		<Arg>
			<Ref id="webAppCtx" />
		</Arg>
		<Arg>BeanManager</Arg>
		<Arg>
			<New class="javax.naming.Reference">
				<Arg>javax.enterprise.inject.spi.BeanManager</Arg>
				<Arg>org.jboss.weld.resources.ManagerObjectFactory</Arg>
				<Arg />
			</New>
		</Arg>
	</New>
</Configure>

Start up Jetty

Jetty is an embedded servlet container that can be easily launched from Maven. Since we added that small snippet to the pom, we can simply type:

mvn war:inplace jetty:run

…and maven will download Jetty and run it with the configuration file we passed.

Test Your Application

Simply load http://localhost:8080/jsf/index.jsf

firefox http://localhost:8080/jsf/index.jsf

Screenshot of your application
If you see the hello world text, everything has worked. Now that you’ve confirmed your configuration is setup correctly, you can explore the more interesting features of Weld and JSF 2, which I’ll be covering in future posts.

Download the Code

The source code to this tutorial is available via subversion here

UPDATE: Tomcat Users

With the addition of a context.xml, this example runs perfectly on Tomcat.
Please see this article for details.

Further Reading

Many thanks to the JBoss staff on the forums who helped me get started in Weld. The artifacts in this article were modeled after their examples.

The Best Care

I’m at a conference at Harvard Medical School today, with various industry and policy luminaries. Federal CTO Aneesh Chopra and HHS CTO Todd Park were just speaking. Reginza Herzlinger is giving a talk right now. Clayton Christensen was here this morning. Gotta love Harvard, and I’ve got a number of thoughts which I’ll wrap into a set of posts over the next few days.

But until then, I wanted to draw out a single point that has recurred a lot in various conversations I’ve had over the last few days. Christensen brought it up again in his keynote this morning. It’s this: the best care for complex disease is delivered by groups of physicians who are coordinated with each other. That coordination comes from being in the same room.

Dr. Christensen’s example (from his book) is an acquaintance spent years looking for appropriate treatment for his asthma. Over several years he saw many different specialists, and they didn’t solve the problem. Then he saw the same set of specialists (different people, same expertise), all in the same room, after flying to Denver. And they figured it out in 30 minutes.

I saw something similar this winter after visiting a microvascular disease clinic at Massachusetts General Hospital. It was a volunteer effort, run on a Saturday morning, with 6 or 7 experience specialists and a few residents and fellows. They saw patient after patient, all of whom had been bouncing through the system – and more or less without exception, they knocked each problem down as fast as it came up.

So here’s a question for healthcare reformers and healthcare technology innovators. How can we create that same quality of care for everyone who has a difficult to diagnose condition?