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……

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

• JSF 2.0 Community Homepage http://www.javaserverfaces.org/
• JSFSpy:  http://www.jboss.org/community/wiki/JSFSpy
• PrettyFaces RESTful URLs http://ocpsoft.com/prettyfaces/
• PrimeFaces JSF Components http://primefaces.prime.com.tr/en/
• RichFaces 4.0
• JSF Summit

All of this has got me thinking about the challenges of building applications on other people’s platforms.  Whatever users may say about Windows, Microsoft has always treated its ISV partners pretty well.  Lots of notice, and no arbitrary barriers to deployment (Apple) or random, substantive policy and feature swings (Facebook).

I have no deep insight here, but I’m curious – particularly in our area of healthcare informatics and public health, how much is platform instability (and profusion!) limiting the development of next-generation applications?  What’s required to justify an investment in these platforms?

As for Android – depending on what the reviews look like, I’ll probably get a Droid next week or the week after, despite my Sprint contract.  I’ve been fully fed up with Windows Mobile for a while, don’t like Blackberrys, and need a sliding keyboard. Hope the application developers keep up…

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

• Information about configuring Cargo.
• Informating about how to configure your settings.xml file.
• My JSF2 + Weld Hello World tutorial.
• Weld Reference Documentation and JSR 299 Specification.
• JSF 2.0 Specification, JSR 314.

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

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

• Weld Reference Documentation and JSR 299 Specification.
• JSF 2.0 Specification, JSR 314

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.

Joel’s article was amusing, but obviously balance is important.

I got the impression the Joel was rebelling against COM, C++, OOP, and general abstraction. I can’t say I personally share his view that complex technology is inherently bad. These features are sharp tools, much like the power tools today’s carpenter uses to build a house. Left in the hands of idiots, sharp tools cause problems. It doesn’t take too much imagination to see how assigning an idiot with a drinking problem and an addiction to cough syrup with the task of ripping boards (cutting lengthwise) with a table saw can cause problems. Likewise, letting someone write multi-threaded code who doesn’t have the skill necessary to handle it responsibly is a recipe for disaster.

Over-engineering is a serious threat to a business, especially since many engineers I have worked with can fairly be accused of over-engineering at some point or another in his or her career. However, there’s obviously a reason things like Object Oriented Programming exist… and it isn’t just because the entire software engineering profession isn’t as smart as Mr. Macho Duct Tape Cowboy.

Everyone reading this who has written code for a large company has seen what happens when duct tape programming gets taken too far.  You end up with a giant legacy system, written by two-dozen authors over multiple decades. The application performs poorly, is difficult to maintain, and no one has holistic knowledge of how the system works. You often find yourself spending 6 months training each engineer which touches the system on your internal proprietary duct tape patterns. Duct tape programming is fine and dandy until you ship something that’s broken or can’t be extended to fit your changing business needs — because it is a giant scary monolith and every simple change in one piece of functionality breaks another piece that was duct-taped on it 5 years ago.

OOP and standardization technologies that abstract complexity pay off when you have more developers that can fit comfortably in a small office and you realistically expect for a product to be handled in the future by people other than its original authors. They add complexity for the sake of compartmentalizing functionality so it can be distributed among different authors and can encourage documentation of the workings of each module.

My team pushes for modern standards and best practices so that we can hire a sharp developer who’s familiar with modern technology, and he can instantly understand most of what we’re doing. More often than not, we could have shipped whatever we were working on slightly faster if we ignored standardization and just did things the way we did them many years ago because it was familiar to us. However, the customer would pay the price when they asked someone other than us to maintain our quickly-shipped, duct-taped masterpiece.

Most professional developers write code for a company for the sake of delivering a quality application, a tool to enhance their business. You do the client no favor by saving them money on the initial delivery and costing them more down the road to keep the product running and relevant… unless you’re solely billing by the hour and are in a situation where they can never fire or sue you.

Clearly this is a complex problem that people are years from solving, but until the geniuses of the world get together and solve this once and for all, I personally think we’re best off balancing writing elegant, standards-compliant code with shipping things on time and not blindly adopting technology without fully understanding the consequences.

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?

One big change from the prior environment is that the business associates of a HIPAA covered entity are now directly covered by the rule. Previously, protections were extended by contract with the original CE. Practically, I don’t think this makes a huge difference, since the Covered Entities would have just gone back and renegotiated the existing agreements to share the notification burden. Extending those requirements through regulation probably even saves some money and lawyer time, since there’s now no need to go and revisit all of those agreements.

The final rule does, however, have a pretty substantial loophole. Notification is required only when there is a chance of substantial harm to the person whose data was released. And that determination is made by the covered entity. Obviously, there is a huge opportunity for things to go wrong here. But the opposite extreme – mandating disclosure at all times – would be overly burdensome and would also have the very negative side effect of scaring consumers who receive breach notifications for trivial things – their city and phone number were accidentally released to a contractor, who then had a laptop stolen while on vacation in Guatemala. Odds of harm to the patient are pretty close to zero, and putting the burden on them to worry about sophisticated identity thieves is not particularly fair.

So I don’t think they got this one entirely right. A public audit process might be the solution – all breaches need to be disclosed, and outside groups can choose to make a stink about situations where individual notifications should have occurred but didn’t. I suspect this would get behavior into line pretty quickly.

Retail clinics, such as CVS’ MinuteClinic chain, are intended to provide an alternative. Rather than going to the Emergency Room, you go to your local drug store, get checked out in a few minutes and are handed the prescription. If your condition goes off-script, they send you to a doctor or to the ER. The clinics are manned by nurse practioners or physician assistants, depending on the state, and supervised by a physician who may be off site.

Until recently we haven’t had much insight into the effectiveness of retail clinics. That’s beginning to change. In the current issue of the Annals of Internal Medicine, Ateev Mehrotra and colleagues analyze the long-term costs of care in retail clinics in Minnesota for the three conditions I listed above. You can read the abstract of the article here.  Here’s the summary:

Overall costs of care for episodes initiated at retail clinics
were substantially lower than those of matched episodes initiated at
physician offices, urgent care centers, and emergency departments
($110 vs. $166, $156, and $570, respectively; P < 0.001 for each
comparison). Prescription costs were similar in retail clinics, physician
offices, and urgent care centers ($21, $21, and $22), as were
aggregate quality scores (63.6%, 61.0%, and 62.6%) and patient’s
receipt of preventive care (14.5%, 14.2%, and 13.7%) (P < 0.05
vs. retail clinics). In emergency departments, average prescription
costs were higher and aggregate quality scores were significantly
lower than in other settings.

In other words – if a patient goes to the retail clinic rather than ER, the insurance company saves $460, and the patient gets care faster and suffers less discomfort.  The quality scores show that retail clinic customers do not suffer in terms of other healthcare services (such as scheduled preventive procedures) compared to those who seek initial care in a physician office.

As we like to say in healthcare economics, this is only an initial study. It’s biggest weakness is an inability to control for severity of the underlying condition – it’s conceivable that only healthier patients took a chance on the retail clinics, leaving the physician offices and emergency rooms to handle a much sicker group. I don’t think this is likely, however. With these three conditions it is difficult for the patient to judge severity when the disease presents itself. Minnesota is particularly well seved by retail clinics – it’s MinuteClinic’s home turf – so access issues are also unlikely to play a role.

In general, I think these are promising results, and they should help encourage insurance providers to reimburse for care delivered in the retail clinic setting. That should help with adoption – the market has not exploded, and MinuteClinic has even resorted to running some clinics seasonally.

Oh, and for those looking for an informatics connection: retail clinics tend to be pretty good at operating electronically and making patient data available to the patient upon request. MinuteClinic, again, was one of the early Google Health partners, and they’ve long seen electronic health information exchange as a key component of their integration with local health systems.