The blog has been quiet for awhile; I just got back about a week ago from my summer break --- a trip to Paris and Rome with my family. We spent incredible days exploring the cities, connecting with history, eating a ton of gelato, and sharing some great (and some not so great but just as enjoyable) bottles of wine. It was one of those milestone trips that will be hard to top.

When I left for Europe, the NHIN Direct project was just starting to pep up again after a few weeks of low energy. Getting to agreement on the consensus proposal was pretty tough and took a lot out of the team. Arien was working hard to kick things back into gear with the new workgroups. Here at Microsoft, my friend Umesh was just starting to get moving on "Agent 2.0" --- the transformation of his demonstration code into the real reference implementation that will support the pilots we'll be spinning up come November. I wrote a brief overview document trying to break up the work, and hoped that when I got back the agent would be in good shape so we could move on to the SMTP sinks and other pieces.

When I walked back into the office last week, Umesh looked up at me with bleary and slightly crazed eyes and said, "I don't think I can get it done."

I wasn't really sure what he meant. Get what done? Was there some new technical problem that meant our approach wasn't feasible? Or was the agent going to take another couple of weeks, or what?

Well, here's the thing. It turns out that what he meant was that he wasn't sure he could get THE ENTIRE REFERENCE IMPLEMENTATION CODE COMPLETE BY THE FACE TO FACE MEETINGS ON THE 17^TH OF AUGUST --- he'd need a couple of extra days. What nerve.

Step back for a second here. I get that this isn't a totally fair comparison, but after years of people talking about healthcare interoperability, in the fifteen days that I was on vacation, Umesh wrote virtually all of the code that will be required to start securely sharing health information across the Internet. Holy crap!

There really are special individuals in the world --- and those individuals do amazing things that the rest of us benefit from.

When I met Umesh on our first day of college in 1987, it wasn't obvious that this skinny Indian kid obsessing over Jean Michel Jarre had that in him. But having watched him knock down challenge after challenge for more than twenty years now (as long as I've known my wife) ... I can say that he is one truly remarkable guy. The kind of guy who explores and questions and makes things happen, whether it's creating code, 80's funk, essays on history or reveling in his adopted country by texting me that "America is cool!" from the Smithsonian.

We are all lucky he's directed some of that talent at healthcare --- thanks, dude.

What a difference a few weeks and TONS OF WORK can make!

Folks in the office are now convinced that I'm completely bipolar. My mood and outlook on life has shifted from minute to minute since my last NHIN Direct post after our face-to-face meeting in Redmond. We're on, we're hosed, not sure, looks great, oh crap.... Repeat!

But I think we can safely say, as Arien did in his most recent official post (best tease on the misspelling of "Houston" goes to Janet Campbell), that we are at least for now in the clear and can see a path towards getting simple messaging going in the real world before the end of the year.

YIPPEE!

So where did we end up? Well, the official consensus statement basically calls out three things (I'm paraphrasing here and the words in the proposal were chosen very carefully, so please use that as the "golden" document):

1. The baseline protocol for exchanging messages will basically be secure email --- an SMTP transport carrying RFC5322-formatted messages signed and encrypted using S/MIME. We have added some additional restrictions to the S/MIME standard (and some of the details are in flux), but at the highest level --- secure email is the base.
2. For entities using IHE/NHIN systems, the recommendation is to "short-circuit" the baseline protocol and use a to-be-slightly-modified XDR exchange when it is known in advance that the recipient can handle that format. These entities must also support the baseline SMTP protocol, but this recommendation provides a path towards migration as/if adoption of the IHE stack accelerates.
3. In our reference implementations, we will create a number of transformations and alternate interfaces, so that developers have the maximum flexibility in integrating NHIN Direct into their products and services.

In the totally wicked department, I got the opportunity to duck down to Santa Rosa (home of Charles Schultz I found out when I got there!) last Friday to participate in a demo of the "current state" of NHIN Direct at the Redwood MedNet "Connecting California" HIE conference. The demo involved folks from Redwood MedNet, Mirth, MedPlus, Microsoft and the Western Health Information Network --- sending data from Care360, to Mirth, to Outlook and then on to HealthVault. The first public demonstration of NHIN Direct --- cool beans!

Now of course we enter the next phase of this journey --- and we have to start building for real deployment and use. After a brief hiatus to celebrate the Fourth, here at Microsoft we're back in business. Umesh is busy working on v2 of and writing a detailed spec for the S/MIME "agent" so that we can nail down final details. I am trying to close out the Security & Trust workgroup recommendations and build an initial project plan for a .NET reference implementation. It's going to be a busy summer --- especially with a pretty chaotic travel schedule between now and August. Party on, Garth!

Exciting news on the HealthVault front this week as we announced the launch of HealthVault in the UK, our third country to go live with the platform so far --- totally cool! Unlike our announced agreements in Canada and Germany, in the UK we are going "direct," running the service ourselves. Organizations that wish to use HealthVault as a foundation for their applications and services can do so using a "subscriber access license" model. We're starting incrementally with our partner Nuffield Health to deliver the My Health Info application to folks in the UK that are actively monitoring their health and wellness --- but of course that's just the beginning.

Microsoft has had a long history working on healthcare in the UK --- and most recently we announced the Milton Keynes NHS Foundation Trust as our first UK customer for Amalga. Adding HealthVault gives us and others a foundation to connect clinical care with individual citizens and their care circles --- I'm particularly excited about the potential for home monitoring solutions.

From this humble developer's point of view, though, one of the coolest things about this launch is how few people in the group really even knew it was about to pop. Why is that good news? Because it means that we've figured out how to scale our baby. Mark and his team get the business work done; Michael and his team make sure we've made any adjustments needed to support local privacy and security requirements; Zach and company airlift some servers into place, and --- Bob's your uncle --- we're running a new instance of the platform. THAT is pretty sweet.

Next stop on the world tour? Stay tuned!

I am not shy about sharing my opinions. Pausing here to wait for laughter to subside. OK.

Often that is a positive, and means that I can help push a group to surface important issues that otherwise get swept under the rug. But sometimes it gets in the way, too.

I also work for Microsoft. I am on my second stint at the company, having returned in 2006 to help found the Health Solutions group after a 10 year journey through the startup world. I am really proud of what we're doing here in HSG, and I am extraordinarily lucky to be in a position where I have a ton of freedom to choose where I focus.

A few months ago, when I read Wes and David's "Simple Interop" posts and then spoke with Arien during the genesis of the NHIN Direct project, I got super, super excited. I spend pretty much all my time trying to get the right information into the hands of patients and providers, and it is really hard in the existing environment. NHIN Direct, with its ambition to short-circuit some of the policy and technology barriers that have slowed this down to date, represents the best chance we've had to really create a ubiquitous way to move beyond this quagmire.

Because of this belief, I have dedicated a huge percentage of my personal time, and that of my team, to push the project forward. The last week or so, I have been very vocal about my concerns about taking an IHE/XD* approach to NHIN Direct. I am comfortable with a number of alternative approaches, but have been championing one (SMTP) that I believe is the best path to quick and sustained success.

Somehow along the way, the conspiracy theories seem to have started to emerge. As I understand it, the central theme is that the reason "Microsoft" is pushing so hard for SMTP is that we are looking to extend our world hegemony with Outlook, Exchange and Hotmail.

My first inclination here is to giggle a bit, and then say "great idea!" But I really care about the success of NHIN Direct --- so I wanted to offer a serious and public response as well.

First --- the incremental units of our email products that we might sell as a result of NHIN Direct are completely irrelevant to that business. None of those groups have even heard of this project. The vast majority of providers are already Mac or Windows Office users already.

Second --- we currently sell an HIE product (Amalga UIS) that includes support for the IHE/NHIN protocols. Selling more of these is incredibly material to the HSG business (and my personal commitments). So if I were simply shilling for Microsoft products, I would be better served espousing a different position.

Everything we are doing in HSG comes back to getting the right information in front of the right people so that they can make better decisions. We sell products to help with that: Amalga on the enterprise side and HealthVault for consumers. Will NHIN Direct help those products? Yes --- but only if it gets used by providers and patients. Without that, it'll just be another silo.

That's my concern --- I do not believe that the business dynamics of an exclusively-IHE/XD* implementation will enable that ubiquitous usage.

I won't go back over all the reasons for that, especially as we are engaged in some very positive conversations about blended concepts that might get us to a consensus position. I just wanted to be clear --- the Death Star is not at work here, and I'd be more than happy to speak with anybody one-on-one more about it if they have questions.

This last week we held two days of face-to-face meetings for NHIN Direct. The goal was very clear: decide on the base technology underlying the simple push messaging system we've been asked to create. We need to do this so that we can move into the implementation phase and deliver value by October. Unfortunately, we did not arrive at a final decision.

But much worse than that, as a group we drifted further and further away from our original charter, slipping into the same business-as-usual, fundamentally flawed approach that has delivered a stunning lack of success over the last decade. The process is now dominated by the same big vendors and organizations that simply cannot see past their current business models and history.

Do I get the irony of taking a position against "big vendors" while using an @microsoft.com address? You bet I do. But this is exactly the problem that is going to make us fail, and it has to be made clear. I found myself unexpectedly emotional trying to plead my case at the meeting yesterday, and have been unable since then to shake my dismay at the risk of losing this incredible opportunity.

Our problem is economics, not technology.

Securely sending a message from point to point is actually an amusingly trivial problem. You can do it with any of a zillion technologies. If that was really the problem on the table, we've wasted a lot of brainpower on this project. But it's not.

The really (really) hard part is identifying which of these options will support the emergence of a scalable, self-sustaining commercial ecosystem, in the short time window we have been given. Or put another way, which approach makes the right people sit up and say, "I can build or grow my business based on that."

To make that assessment, we need to understand who is likely to be providing services to that huge majority of small practices that have, so far, opted out of the EHR market.

The only answer to this is, it'll be the same small-to-mid-size ISPs, SAAS vendors and VARs that these offices work with today for their practice management and other office needs. It is clearly NOT Epic, Cerner, IBM, GE, or some government agency. I'd say it's not Microsoft either, but I'm not quite as sure about that --- we do deliver millions of boxes of Windows and Office to these doctors, and provide many of their non-clinical email services, so we at least have something to start from. Google is in a similar boat as us, with Google Apps and their other productivity products. So put us both in the "maybe" category.

So our job, then, is to identify the package of technology that will:

1. Solve the technical problem of moving messages around securely;
2. Be more convenient for doctors than the fax machine;
3. Provide a credible path from unstructured to structured exchange; and
4. Be attractive to these ISPs and VARs as a commercially-viable extension to their existing product lines.

If you've ever been part of these small service businesses (and I have, albeit not in healthcare), you know that the key to maintaining your profitability is to be laser-focused on managing operational costs. This generally translates into leveraging your investments in as many different ways as you can. Training and paying staff to administer systems and help customers is expensive. Billing management is complicated and expensive. Being sure that you can host the maximum number of customers on one physical piece of hardware is really important. And so on.

My big mistake

I thought we all got this as part of first principles. Oops.

Because I thought this was a given, I've been spending my time on all the "secondary" issues ... how can we manage certificates, how do we make sure policy variance doesn't stop us, how do we integrate with existing infrastructure like email and DNS, how do we make sure that the client is simple to manage so the providers don't need extensive (and expensive) hand-holding, and so on.

When these issues didn't seem to resonate with the room over the last week, I was really confused. But then I took a closer look around, at the problem became obvious. These were all huge IT vendors that sell to hospitals, huge systems and the government (or they actually were the government). We had almost zero people who think about the real IT and economic environment these small businesses (both the providers and services) live in. All the usual suspects.

Holy misaligned frame of reference, Batman!

Why "IHE" won't create a winning ecosystem

The people who support small practices today will not stand up an IHE SOAP/XD* stack. Well, wait a second --- a few will, sure. You always have folks who are willing to make a visionary bet. But at scale across the country, so that a small provider can sign up for a $10/month service plan? No. Freaking. Way.

The first problem, of course, is that the IHE SOAP stack is incredibly complex and poorly documented. Anybody who has tried either path --- implementing a stack or configuring a CONNECT server --- will tell you it's crazy. Even the strongest proponents of the technology readily admit this. They say "we just need to fix it" --- but somehow we got to where we are. Why do we believe we can suddenly just make that better? I don't get it.

And even if it were easy to get your arms around what it means --- it means a brand new type of application. How you provision users will be brand new. How you make backups of the message store will be brand new. How you learn about security vulnerabilities and patch the system will be brand new. How you configure your firewalls will be brand new. The training needed by customer service staff will be brand new. The way you monitor the system to see if it's healthy is brand new. The way you try to determine why a message didn't get delivered is brand new. I could go on for hours here.

And by the way, there is zero software written that would help you run multiple organizations on a single machine, or meter and bill customers. This kind of thing just hasn't been on the radar of any of the organizations working within IHE.

Finally, most of the potential service providers have never heard of XD*. Try to imagine how you would respond to these two questions:

1. Do you want to get into the "NHIN Direct" business? It's a new service for small providers that lets them communicate securely. I can send you a link to the site where you can learn about IHE and the SOAP/XD* profiles to get started.
2. You already provide email services to your clients. We've created this thing called "NHIN Direct" that extends your existing email infrastructure so that providers can use it to share clinical information securely. It would be a great "upsell" to your existing product line, so you can capture additional revenue from your existing customers.

Does the difference seem subtle to you?  If so --- you haven't worked in that business before.

All is not lost

Like I said at the beginning, we didn't actually pick a final winner yesterday --- although the leanings of the room were trending towards an IHE XD* solution. Arien collected up all of the objections for each possible solution (IHE, HTTP/REST, and SMTP) and asked that the teams formally respond to them in advance of some intensive last-mile wrangling this coming week. I've started our responses for SMTP here.

More importantly --- we need to hear from the folks that are really in the field: small providers, their VARs and ISPs, and their representatives. The AAFP and CGC are two organizations that have weighed in in support of a more appropriate option already - we need to hear from more. You can help by posting your thoughts to the NHIN Direct Google Group.

Unfortunately, these are the very folks who are busy doing the real work of healthcare, so often aren't able to invest the kind of time I've been lucky enough to spend. To those folks --- and to Todd and Aneesh who cleared a ton of roadblocks to create this incredible opportunity for us --- I feel badly for where we are, but will keep working to try to make it a success.

John Moore wrote an interesting post this weekend asking if Google Health was at risk of shutting down - and wondering if the resulting lack of competition would cause us here at Microsoft to let HealthVault stagnate. John is really good at bringing up the provocative questions.

I don't have any great information on the first one. It's clear that the folks at Google are working with a much smaller investment than we are, but I still see them plugging away on their developer forums and as part of groups I'm spending my time on like NHIN Direct. They still seem like they're making progress to me. Who knows.

As for the second one --- well, don't be concerned. Because while it's always fun to play Spy vs. Spy with Google, our real competition is the idea that any one provider or company can solve the problems facing our healthcare system today. The problem is tethered single-system PHRs and portals that say, "I'll take care of everything for you, even though I only handle a small fraction of your actual care." It's EMR vendors that say, "Sure you can report on our data, so long as you don't ask anything we haven't already thought of." And it's short-sighted politicians that stifle market innovation by perpetuating "pay-for-volume" as our primary industry incentive.

See, that's why I believe Microsoft is the right company to help, and why I'm here as part of the effort. HealthVault is a critical component in our broader project strategy --- which is to (1) connect care across the ecosystem, from the home to the clinic to the hospital to the research lab, and (2) do so in a way that includes and encourages innovation from as many different organizations as possible. Frankly, we bring pretty good DNA to the party for both of these objectives.

We're all for an army of patient activists, but we aren't so naïve as to believe that the availability of an online tool is going to get everyone excited about tracking their health history. Much to the contrary, the success of HealthVault will be in how invisible we can make it: automatically helping you prepare and register for visits with your hospital and providers; encouraging "guardian angels" that watch over your data and alert you when something dangerous may be going on or when new treatments are available; or ensuring that the right people have the information they need to care for you in an emergency. Trust me, we're hard at work on this stuff!

So don't make the mistake of evaluating any one piece of the puzzle in isolation. Microsoft is in this game because we believe we can make a real difference in the quality and efficiency of care, and that we can deliver significant value for our shareholders while doing so.

Just keep swimming!

(This post was recovered after my blog meltdown ...)

Wow --- this is just fantastic news. Dr. David Magid at Kaiser Permanente Colorado used a combination of:

• home monitoring using HealthVault-connected devices,
• patient self-care with the American Heart Association's Heart360 application, and
• a HealthVault application that moves measurements into Kaiser's EHR for review

...and found that "at six months, patients in the home monitoring group were 50 percent more likely to have their blood pressure controlled to healthy levels compared to the usual care group." (Usual care involved typical practice of measuring blood pressure during office visits.)

What's that I hear? Oh right --- the sound of AWESOME!

Patients using home monitoring were 50 percent more likely to have their blood pressure in control

DENVER and REDMOND, Wash., May 21 /PRNewswire/ -- The use of at-home blood pressure monitors and web-based reporting tools that connect clinicians and patients via the Internet appears to significantly improve patients' ability to manage their high blood pressure to healthy levels, according to research from Kaiser Permanente.

The study, led by Kaiser Permanente Colorado in collaboration with the American Heart Association and Microsoft Corp., involved 348 patients with uncontrolled hypertension, ages 18-85 years. The initial study data was presented today by Kaiser Permanente Colorado researchers at the American Heart Association's 11th Scientific Forum on Quality of Care and Outcomes Research in Cardiovascular Disease and Stroke.

"Kaiser Permanente Colorado's Institute for Health Research is committed to studying innovative ways to make care more patient-centered in order to improve quality," said lead author David Magid, MD, Kaiser Permanente senior scientist. "While more research is necessary, our study suggests that using technology to engage individuals in their care at home may be a better way to help patients achieve a healthy blood pressure."

As many as 73 million Americans have high blood pressure (hypertension), a leading predictor of heart disease. According to the American Heart Association, approximately 69 percent of people who have a first attack and 77 percent who have a first stroke suffer from elevated blood pressure levels. The participants were randomized to a usual care group or a home monitoring group. All patients had their blood pressure measured in the medical office at the start of the six-month study. The usual care group was managed in a typical model that involved checking blood pressure during office visits.

The home monitoring group used an at-home blood pressure device that uploaded data to the patient's account in Microsoft HealthVault, a security enhanced, Web-based data storage platform. At the time of entering the study, the participants opted into a Kaiser Permanente application that automatically transferred the home blood pressure readings to Kaiser Permanente's electronic disease registry. Kaiser Permanente's clinical pharmacists used the computerized registry to monitor readings and consulted with patients to adjust their antihypertensive medications based on proven protocols. Connected to HealthVault, patients were able to manage their data using Heart360, a free online tool provided by the American Heart Association.

At the start of the study, the average systolic blood pressure was 149 mm Hg in the home monitoring group and 145 mm Hg in the usual care group. At six months, patients in the home monitoring group were 50 percent more likely to have their blood pressure controlled to healthy levels compared to the usual care group. Similarly, a significantly greater decrease in systolic blood pressure at six months occurred in the home monitoring group (-21 mm Hg) versus the usual care group (-9 mm Hg).

Health experts have long known that the current approach to managing hypertension has its shortcomings. Patients often don't comply with in-person visits and when they do, the measurements can be inconsistent or inaccurate. In light of these shortcomings, the American Heart Association recently began recommending home monitoring. However, prior research conducted by Dr. Magid found that when patients used home monitoring, but were required to write down and call-in results, blood pressure goals only slightly improved. This latest study provides an additional layer of automation and convenience by directly feeding the readings from the home blood pressure cuff to the patient's care team via sophisticated health-IT tools.

"While the in-person doctor-patient relationship will always be a cornerstone of care, one day the use of coordinated, secure health information technologies based at home or work could complement visits in a medical office," noted coauthor Kari Olson, PharmD, a clinical pharmacy specialist at Kaiser Permanente Colorado.

"Engaging patients with tools that make health management more accessible is a critical step in addressing the alarming growth of chronic diseases and associated increase in costs," said Peter Neupert, corporate vice president of the Health Solutions Group at Microsoft. "The preliminary results of this clinical trial are significant and demonstrate how cost-effective and flexible technology solutions can encourage patients to be active partners in their health and help decrease their risk for life-threatening, acute care incidents."

This Kaiser Permanente Colorado research is part of a larger effort at Kaiser Permanente to study remote monitoring and connected telehealth to deliver health care at a distance outside of the traditional health care facilities.

About Microsoft HealthVault

Microsoft HealthVault is a personal health application platform designed to put consumers in control of their health information. HealthVault provides a privacy- and security-enhanced foundation on which a broad ecosystem of providers can build innovative health and wellness solutions such as personal health records, disease management, fitness, weight loss and other Web applications. HealthVault can be used to collect and store health information that would otherwise reside in disparate systems and transfer the information between a variety of providers' health services and systems. It enables the reuse and free flow of interoperable and transportable personal health information.

More information is available at http://www.healthvault.com.

About Microsoft

Founded in 1975, Microsoft (Nasdaq: MSFT) is the worldwide leader in software, services and solutions that help people and businesses realize their full potential.

About Kaiser Permanente

Kaiser Permanente is committed to helping shape the future of health care. We are recognized as one of America's leading health care providers and not-for-profit health plans. Founded in 1945, our mission is to provide high-quality, affordable health care services and to improve the health of our members and the communities we serve. We currently serve 8.6 million members in nine states and the District of Columbia.

Care for members and patients is focused on their total health and guided by their personal physicians, specialists and team of caregivers. Our expert and caring medical teams are empowered and supported by industry-leading technology advances and tools for health promotion, disease prevention, state-of-the art care delivery and world-class chronic disease management. Kaiser Permanente is dedicated to care innovations, clinical research, health education and the support of community health. For more information, go to: www.kp.org/newscenter.

http://www.kaiserpermanente.org

SOURCE Kaiser Permanente

So it appears that Microsoft updated the blog software running Family Health Guy ... and my templates, images and at least one post got nuked in the process. Great. Well, I'll be figuring that out over the next few days --- thanks for your patience!

As I've said, it seems that my life has turned into "All NHIN Direct, all the time" --- which is presenting a number of challenges given that I have this day job building software as well (not to mention being behind on my obligations for the Community Health Data Initiative --- sorry Greg, we're getting there, honest!).

Despite that, the time is clearly worth it --- I am increasingly excited about the potential for NHIN-D to be ones of those things that really changes the game. We've seen again and again how secure messaging can dramatically improve practice through our partners like Kryptiq and RelayHealth, and to have that type of capabiltiy available to all providers and patients would be game-changing.

Anyways, I'm engaged in a number of discussions and workstreams over on the wiki, and I thought it'd be useful to hilight some of that discussion here as well. If you have thoughts or would like to participate -- we'd love to have your help!

From http://nhindirect.org/The+case+for+SMTP:

The goal of NHIN Direct is to enable direct messaging from one endpoint to another, where the sender has decided out of band that the exchange is appropriate and complies with all policy and regulation relevant to their situation.

Really, this is just email for health information. If you were to magically make all of the security, privacy and spam/phishing-related issues of today's Internet mail go away --- we would be done!

• Email scales from small practices to large ones, and to patients.
• It is supported across all platforms by a ton of robust, real-world proven software that handles all the edge cases: admin, monitoring, provisioning, etc.
• Its store-and-forward design is resilient in the case of network outages.
• It enables both unstructured and structured exchange.
• It supports endpoints that are humans, groups, or computers.
• It uses concepts that are widely understood and accepted.
• Etc.

I think there would be pretty universal agreement that this would be a no-brainer. So the question becomes --- is there a minimal-code approach we can take to achieve the "magic" we need?

As it turns out, email gives us an answer for at least part of the magic, too. S/MIME provides a standard, well-understood mechanism to use digital certificates to both encrypt email messages - ensuring that they are not inadvertently disclosed as they travel through the email system - and sign them - ensuring that senders can be tracked and untrusted messages get bounced back.

The obvious question then is - if it's so great, why don't we all use S/MIME for all of our email exchanges already? The answer is pretty simple. Current S/MIME implementations put a pretty nasty burden on the end user - every user has to acquire a certificate for their account, install it, remember to renew it when it expires, and keep track of certificates for others in their address books. Some enterprise systems reduce this burden somewhat, but without ubiquitous usage, it's just never caught on.

This is where we can add a bit of software to the existing stack to make the magic we need. We already have an advantage in that the healthcare community understands and accepts the need to have a secure and trustable exchange - so our solution doesn't have to be ZERO work over normal email, just small enough that it is manageable and easily adopted by end users and their email providers.

We have proposed the "NHIN Direct Agent" --- a piece of code that can be inserted into existing email pipelines --- to manage the handling of certificates and mechanics of S/MIME signatures and encryption. This approach also requires an improved mechanism for distributing public certificates, which we can solve using DNS records - again leveraging already-deployed infrastructure to avoid new work.

The agent can be inserted at many levels --- at the email server (hosted by a service provider or owned by a large organization), at the organizational boundary (as an email proxy or gateway), or on an individual client desktop (as a personal proxy or a plug-in to existing software). These different approaches not only enable maximal reuse of existing systems, but are the key to making S/MIME usable for all constituents: responsibility for certificate management can be delegated to a service provider, managed by an organization, or kept at the level of the individual if desired.

I will refrain from going into more technical detail in this note --- we are hard at work building on those technical documents and writing code to prove the approach. The takeaway I am hoping to leave people with is not those details, but the bigger ideas that:

• We are trying to build email for healthcare.
• Except for a few key flaws, email works extremely well already.
• Those flaws are addressable with minimal and well-understood new work.

This approach is in direct contrast to others that are building up entire new messaging stacks or trying to adapt ones that are "close" but don't exactly fit the need. While I am sure we can do either of these - they seem strange paths to take and high hills to climb, especially when you take into account the huge amount of "last mile" work required to make a new stack truly Internet-ready. The SMTP approach is simple and just makes sense.

12:40am and here I am in Washington, DC after some great discussions at New York Presbyterian during the day and a treat of a ride on the Acela Express down the coast during the evening. I really should be in bed --- we have seven hours of NHIN Direct discussion scheduled for tomorrow -- but the guilt of leaving my blog untended for so long has finally reached un-ignorable proportions.

As it turns out, NHIN-D is really the primary reason for my radio silence. Between me and Umesh we are spending a ton of time trying to help push this initiative forward. So far at least, the time investment has been more than worth it - it really is a moment in time where things seem to be aligning for real progress. I am super-excited.

So what is NHIN-D anyways? The elevator pitch is easy: NHIN-D is secure email for docs and patients. Just give your address to your provider and they can send you your immunization report, recent visit summaries, whatever. A provider looking for a second opinion can safely send background information to a specialist. Lab systems can send results to patients and providers. Pretty simple, really.

Well --- simple once we get all the edge cases figured out. I seem to be finding myself in a bit of a middle position, trying hard to keep things as simple as possible, but not so simple that we miss critical requirements necessary to make the system adoptable, durable and truly useful. The good news is, there are a ton of great people committing real brainpower to working the issues through --- I am honored and lucky to be part of the team.

The last couple of weeks have been particularly fun because we've started to transition from "talk" mode to "do" mode --- time to let the code talk and see what really sings in the real world. And that means a new level of responsibility for participants; we're asking folks to contribute working code to a set of volunteer concrete implementation groups as part of a bake-off to help us make informed decisions about the next level of system detail.

Here at Microsoft we're putting our marbles behind an SMTP-based implementation, creating an agent that can sit within existing email pipelines (like this or this) and handle our still-emerging security and trust requirements. Our premise is that:

• email works pretty darn well for trillions of messages every day,
• there is already a ton of battle-tested code supporting it, and
• it scales easily from small-practice web clients to deep EMR integration.

We hope to write as little code as possible; Umesh told me a couple of hours ago that he is nearly done with a first cut of the agent implementation --- so when I get home we just have to start plugging it in to show an end-to-end working pipeline. WOOOOO HOO!

 OK --- 1:14am now and really time to get some rest. Hope to see you around the NHIN-D Wiki --- we can use all the help we can to get this stuff running!

It appears that Spring is on its way to the Pacific Northwest - the mountains and evergreens are showing themselves outside my window, just like in Doonesbury when Mike worked for Bernie in high tech. And with another Spring comes another Microsoft Connected Health Conference --- we would love to have you join us, May 19^th and 20^th at the Meydenbauer Center in Bellevue.

This is the fourth CHC for us (although the first in 2007 was under NDA!) - this year, our theme is about catalysts for change spanning the clinical ecosystem. We're focusing on improving real scenarios leveraging our entire suite of end-to-end solutions, from consumers and patients with HealthVault to providers and researchers with Amalga UIS, Sentillion and HealthVault Community Connect.

Our emcee for this year's event will be Ian Morrison, author of Healthcare in the New Millennium: Vision, Values and Leadership. In addition to a ton of partner and customer stories and demonstrations, we'll hear from folks like Stephen Dubner, Todd Park, David Brailer and Rod Hochman. As in previous years, we'll run both business and technical sessions and have built in a bunch of time for networking  - should be a lively couple of days!

As I understand it, they've even reserved me a room so I can have one-on-one meetings with folks. Which means you have to come, if only so I won't be sitting sad and alone waiting for somebody to visit. My room is going to have rocking tunes --- and maybe I'll even bring cookies...

Use code CHCREG10 at the registration site to reserve your spot --- look forward to seeing you there!

Every Monday, the folks who manage our HealthVault partner relationships have a meeting called "What's Going On?" where they talk about the applications and devices that have "gone live" in the last week, issues that partners are facing we need to be aware of, that kind of thing. This week they asked me to come by and demo my Withings WiFi-connected scale, which is now LIVE on HealthVault  --- woo hoo!

People were laughing at me because I got so excited about it --- but it is a truly exceptional product, a beautiful piece of hardware, and I am thrilled it is now part of the HealthVault family.

Why such a big deal? Because Withings has really thought through what usability for a scale means - where it fits into daily life -- and delivered from start to finish an experience that just works. It's a huge step forward.

First of all, it's just a great looking product that even my wife is happy to have sitting in the bathroom. When you open the box, the scale has a cling sticker on it that simply says http://start.withings.com/. Visiting the site starts a configuration application so you can configure the scale with your home WiFi information and set up initial users - the scale can manage up to nine different people.

From there the device never needs to see a PC again. It lives in your bathroom --- where you want it, not next to a computer in your office somewhere. Step on the scale and it turns itself on and auto-detects which user is standing on it by matching the current weight to the best-matching historical weight it's seen. But wait, there's more --- if the scale can't be sure which person is using it, the built-in LCD screen shows a choice and you simply lean in the direction of the correct one. Just fantastic --- I am blown away.

Step off the scale and your weight, fat mass and BMI are transparently sent to Withings' Internet servers and tucked away in your account. If you'd like to use your readings with HealthVault (or any of a number of other services), just visit http://my.withings.com/ and use the "Share" menu item to link a user with a HealthVault record. From that point on every reading is immediately available to any HV application or HV user you'd like to share with.

Anyways --- in case it's not obvious, I could not be more enthusiastic. The scale is available for purchase from their site for $159US --- to celebrate our new connectivity, Withings is offering a free shipping promotion ($9 value) if your order by clicking through this link. What are you waiting for?

Cédric and team --- great job.

PS - Yes, I know we weren't first with this one. But hey, we had to give the good folks from Mountain View something to talk about at HIMSS this year! :) Sorry, couldn't resist --- of course it makes great sense for Withings to connect anywhere that there are users, they have been super-smart this way. That's the way this consumer empowerment thing works, folks!

A few weeks ago I was listening to the radio on my way to work and came across an interview with Dr. Atul Gawande talking about his book The Checklist Manifesto. He's kind of taken the world by storm with a really basic idea: maybe if we used simple checklists to ensure consistency in surgical procedures, we could save some lives.

Maybe indeed. When Dr. Peter Pronovost at Johns Hopkins ran a study using checklists to combat bloodstream infections in the ICU, he documented a sustained 66% reduction. When Dr. Gawande deployed a surgical checklist at eight test hospitals as part of a World Health Organization study, major complications dropped by 36%.

And yet the vast majority of procedures in the world are still performed, every day, without checklists. Are you kidding me? We simply must get better about folding this kind of learning back into daily practice.

Well, as it turns out, this is one of the primary design principles underlying the Amalga Unified Intelligence System --- figure out what works, then do more of it, and fast.

As soon as I got to work that morning, I ordered Dr. Gawande's book and (thank you Amazon Prime) a couple of days later I was scribbling down design ideas for a "checklist extension" for Amalga that would allow our hospitals to quickly create checklists, put them into daily practice, and track their use to continually improve performance over time.

A few weeks later, and I've just published that extension up to our community portal where it is available to any Amalga customer as a free add-on to the product. The extension includes the WHO surgical safety checklists as a starting point, but supports creation of lists for any scenario, from complex interventions to making sure rooms are cleaned properly.

This quick video shows the feature in action:

So, what are the key takeaways?

1. You should be implementing checklists in your practice --- there is more than enough evidence to justify the cost of implementing them.
   
   
2. If you're an Amalga customer, the Checklist Extension is a super-easy way to get started - and one that will maximize your ability to see and improve its effectiveness in your organization. If you would like to learn more, your CRM can help --- or just drop me a note.
   
   
3. Amalga is awesome. I mean, come on --- I just got back from HIMSS and the amount of blah blah blah going on out there is nuts. This is real, and can really help.
   
   

Enough said!

The last few weeks before HIMMS are always a flurry of activity in the Health IT ecosystem. I'm not sure if many messages really get through all the noise, but the pressure of having to deliver demos, deals and code definitely makes for a good forcing function in an industry where too often people are happy to "just wait another month."

For the HealthVault team, that means they're busy working through a ton of applications trying to get their services and applications hooked up to the production system. As I heard Lowell shout down the hall yesterday --- "It's Go-Live Season!"

Actually, it's not just HIMSS --- it's clear that the industry has really turned a corner on personal health. Never as fast as anyone would like of course, but we are seeing real acceleration in both the number and quality of applications and devices being built and connected to HealthVault.

Of course, in an environment as crazy as healthcare, having everybody ask "how can I get it done" makes for a ton of work. We've put our stake in the ground as the "hub" of information sharing for consumers and patients, which means we have to connect with anyone who wants to play. It's the right place for Microsoft to be, but it isn't easy. Because there is such huge variation of IT adoption across the healthcare ecosystem, those connections happen on everything from paper and faxes to any one of hundreds of clinical software packages or exchanges.

The end result is that, with so many options, getting started with HealthVault can be kind of daunting. Are you a native app or a linking one? Online or offline? Optional auth? SODA or DOPU or D2C? ABCDEFG? Ack! And of course, when you're running as fast as we are today, good documentation and guidance is always the last thing that gets taken care of.

The good news is, we have an incredible team of people who have built a ton of expertise over the last two years, helping partners figure out how to make their way through the noise to determine what makes sense for their situation. 

Shamez is one of those folks-the kind of guy who can look at a situation, line it up against the HealthVault "toolkit," and articulate the key options and tradeoffs with remarkable clarity. I am really excited that he (with the help of others in the HealthVault team) has put together a fantastic document that tries to capture our best guidance in a way that allows us to "scale up" our ability to answer that omnipresent question: "how can I get it done?"

We've posted the document up on MSDN --- if you have any interest in the details of getting your application or organization connected to HealthVault --- I would strongly recommend checking it out:

• XPS Version
• PDF Version

Part of my job is proving to tech folks at potential customers that our products really can do what the sales guys say they do. The things you can make happen using HealthVault and Amalga are pretty fantastic, and naturally people want to know if we're for real or, well, full of crap. The first thing I am always careful to say is --- there's no magic. We've built some great tools, but they're the result of a ton of work and some novel founding principles. From that starting point, we can have a discussion that shows how we deliver what we promise (and we do!).

But once in awhile --- there really is magic.

Tom Jackson and Stuart Bowers work on Amalga Life Sciences, which builds on top of Amalga UIS, adding tools to aid in life sciences research and development. They are both crazy smart. But beyond raw horsepower, these guys share a passion for solving problems that just makes me sit back and shake my head.

As it happens, Tom and Stuart are fitness enthusiasts, and in their spare time, at home, they've built an incredible gym that watches them with cameras to identify when they're working out and what they're doing. It automatically captures super-granular data from weight machines, spin bikes, dance machines and even universal machines. All this data goes up to HealthVault using a SODA application they've built.

Here's more about their work, in their own words:

Tom and I have been working on a hobby project recently and wanted to take the opportunity to share some of the work we've been doing to capture our health and fitness data and get it into HealthVault. For a few years now we've each been tracking our data, but rarely in formats which were computable or persistent in the cloud, for example written records in a notebook or camera-phone pictures from arcade dance machines. In our current house we've built out a modest gym but now there is more data than ever to keep track of, and with busy schedules it's already hard to fit in a workout and harder still to take time afterward to enter it into a system like the MSN Health and Fitness portal.

We set out with the goal of keeping as much of our health and fitness information in the cloud as possible, while reducing the required user interaction to a minimum. It's been a fun ride and only recently did it truly become possible with the release of the new Software on Device Authentication (SODA) APIs for .NET from the HealthVault Team and a high-resolution webcam from Microsoft.

We've compiled a short video (7 minutes) showing a walkthrough of our gym and the HealthVault integration. If you have the time I'd strongly recommend watching it before reading on.

A short video of our home gym (also available in MP4) --- Note: The video is a WMV file hosted in Windows Azure. If it does not launch initially, open Windows Media Player and press Ctrl+U to enter the following URL: https://tjackson.blob.core.windows.net/videos/GymOfTheFuture_Walkthrough_720p_1600kbps.wmv

As you can see in the video, one of the most exciting things about this project has been the ability to really start keeping our data and trusting the system to track us. If Pam and I choose to go use the spin bikes at the ProClub (which offer wattage output :) we can just bring our thumb drives and uploading data is literally a few clicks away when we get home (via a custom app that Tom and I built for LeMond data). Similarly if Tom goes for a bike ride he can simply use the heart rate monitor from the gym and that data is preserved and can be uploaded via the same app we've built. Most notably though, if we all decide to workout at home, I can transition between weightlifting and spin biking to keep my heart rate up, and I never need to worry about tracking that data explicitly and I can even get real-time feedback that the system is working and my data is being uploaded. At the same time, Pam and Tom can track all of their In the Groove data on jump-drives and after the workout, it's literally a few clicks to get that data into HealthVault where it accessible to multiple applications including our own.

One of things we've started to notice is how liberating it is to know that the system is watching. For instance, most good personal trainers will have you do as many reps of an exercise as you can do comfortably, rather than making you count to a specific number. On strenuous activities like the bench press, counting reps can break your focus, but it's critical to determine if you should add more weight. Recently I've taken to simply lifting as hard as a can, then poking my head in the other room to see if I was pushing myself hard enough. It's an amazing feeling to literally have a virtual personal trainer. Similarly I try to get in at least 20 minutes on the spin bike, but jumping on and off of the bike during the workout makes it tricky to track that. I used to try to keep a running tally in my head but I'd often lose the count as I focused on weightlifting. Now if I ever get lost I can just poke my head around the corner and see a running tally displayed in HealthVault!

So far the system has been amazing to work with and HealthVault has proven to be the perfect platform for storing the data. We've even made a simple WPF app to show what days we've exercised and whether it was cardio or weightlifting, rendering our paper calendar obsolete.  As I mentioned above it's been an awesome ride getting everything working but we're pretty sure that the real fun is yet to come. Moving forward we are excited to keep pouring this high resolution data into HealthVault and start using it both as a motivator and as an opportunity to learn more about our own health and wellness.   

I still can't stop grinning like an idiot when I watch this video. First of all, it's INSANELY cool. Second, it is a great reinforcement of the promise of what we're enabling with HealthVault and our other projects. And third, with folks like Tom and Stuart working here, I know Microsoft is bringing the chops to make it all happen.

Last Friday, I had a chance to speak, along with Dr. Craig, to a pretty cool group of folks in Washington DC about how we think about creating data-centric assets, and why we think it's important to inject some new concepts into our national conversation about healthcare quality and research. It was a good conversation, and it seemed like there were at least a few "a-ha" moments for people over the course of the day (myself included).

That evening, as we sat on the tarmac at Dulles awaiting our second de-icing in a last-ditch attempt to get out from under the big storm, it occurred to me that I hadn't ever really written about this, and that perhaps I should do that while I was stranded in the airport terminal over the weekend. As it turns out, we made it into the air and I spent a much more entertaining weekend at home watching Avatar (awesome) and enjoying holiday meals at Elephant and Castle (bangers and mash) and Artisanal Brasserie (pork belly hash). But now I'm back at work - so time for a few thoughts.

When we talk about Amalga UIS helping to create data assets - what are we really talking about, and why is it any different than a traditional data warehouse? Glad you asked!

All the data...

A data asset is a collection of all the information relevant to an organization, regardless of source and of type. We call it an "asset" because this data, not the systems that created it or that are used on any given day to interact with it, represents the true long-term capability of an organization to thrive. The potential of that organization to measure itself, to learn, to adapt to new situations and technologies, to predict future outcomes and improve operations, all rely on its ability to find, use and re-use data.

This is what Amalga does - it captures all the information, and stores it in data atomic form. "Data atomic" means that rather than try to selectively normalize incoming data elements into some predetermined information model, we simply capture them exactly as they arrive - and save every scrap of metadata that comes along with them in self-contained "data atoms." By doing this, we ensure that we never lose fidelity, history or context.

In contrast, a traditional data warehouse makes its judgments at ingestion time about what attributes are (or are not) important, and normalizes the information "up front" in an attempt to create a cleaner and more easily queried data set. We just flat out think this is the wrong choice - because the time you receive information is the worst possible time to lock down and limit how it can be used.

Instead, the right time to make decisions about data structure and normalization is "just in time" - when specific information is going to be used for a particular purpose. That purpose will dictate which elements are important or valid, and what kinds of transformation or normalization need to be applied. The key is to realize that the "right choices" will change from use to use and day to day; unless you've retained the full-fidelity, original data and meta-data, you can never be prepared for the next question you run into down the road.

This makes some people really uncomfortable. Data in the repository could be contradictory, or maybe there's information in there that can't be translated into this or that coding system. And for sure that's going to be true, but the alternative - frankly, willful ignorance -- is a whole lot worse. In the Amalga case, you've at least got a full representation from the best sources of truth available. You can do queries on that data, present it to users to be interpreted, and generally use it in a lot of ways, even in its "messy" state. And when or if the time comes for you to do a particular normalization pass, you still have all the raw information you started with - so you can do at least as a good a job as you could have back when you first received the information. With a traditional data warehousing approach, if it doesn't fit some incomplete preordained model of the world - onto the floor it goes.

In Real Time...

Another key attribute of a data asset is population in real time, message by message - rather than by batch process. Pivoting an organization to be truly data-driven demands an understanding of how things are going right now - not how things went over the course of the last quarter. A fully-leveraged Amalga data asset is a central part of daily operations, feeding worklists on the floor, raising alerts when service levels drop below acceptable levels, delivering images and reports back to folks who are waiting for them, and driving quality dashboards that point the way towards action, not just reflection.

This demand for real time information needs to extend beyond the walls of our institutions as well. The nation is defining a set of "meaningful use" outcome and quality metrics that will become the yardstick we use to understand how we're doing, what works - and what does not. Why should we accept a world where we fly "blind" until institutions report their aggregated numbers every quarter? We need a national data asset - there is no reason we shouldn't be able to track granular outcomes on a real time basis - and catch events like regional e-coli outbreaks within hours rather than weeks.

And Fast, too!

Of course, the astute reader is screaming out that one big trick remains. Holding all this data, in its original form, with all its metadata - how do you possibly answer questions with acceptable speed? After all, EAV tables and variant columns don't lend themselves to great performance in the real world.

Amalga handles this by leveraging the fact that - when you've got all the original data - you can "extrude" as many different transformations of that information as you need. Today's reality is that storage is cheap - really cheap - so we've solved this problem by creating a pipeline that allows data to be cast and re-cast as needed to deliver performance to support any type of query.

That "re-casting" is the critical piece. Like everything about Amalga, performance optimizations are flexible and "just in time." Query patterns evolve over time - and the pipeline process makes it super-easy to go back to source data and create new views, pivots and transformations to support those evolving needs.

I am really proud of the products we've created and assembled here in Health Solutions. "Connected Health" is exactly the right approach for the nation, and it's one that Microsoft has the right DNA to deliver on. Comprehensive Data Assets are a central piece of that connected story - and when you see things start to fall into place and the usage goes viral - you just know you're on the right track.

I have been lax in acknowledging another awesome idea to emerge from recent discussions about how to accelerate progress around data exchange. Just before Thanksgiving (and my daughter's 16^th birthday!), Wes Rishel wrote a post in which he proposed that we might short-circuit the daunting and messy current requirement of full transitive trust for participation in the NHIN:

"This approach relies on an assumption: that the business trust between organizations that use EHRs and the organizations that receive data from them or send it to them can be addressed without the full formal architecture of transitive organizational trust that complicates the HIE+NHIN approach.

Organizations that exchange data would use the postulated simple Internet mechanism to exchange information with other organizations which they had independently determined to trust."

This - is - an - AWESOME - simplfying - approach.

The idea that we can create some kind of fully-trusted space for health data exchange is really, let's be honest, nuts. Not to mention incredibly dangerous. And as far as I know, it doesn't match any other heterogeneous ecosystem in the world.

Participation in "the NHIN" should simply be a matter of implementing the right protocols and having sockets open on the Internet. Anybody should be able to plug in, just like they can plug a web server into the web. That doesn't mean that anyone will trust them to exchange data, but that's just a separate issue.

Point-to-point trust will actually get us a long way. State health authorities could certainly register public keys for all of the healthcare entities in their region to accept reporting data. Affiliated organizations could flip the switch to talk to each other. Consumers could choose to connect with individual facilities they work with. It's really pretty powerful.

But --- it has limitations too. For example, the state might really want to trust "any Washington-state certified provider" when accepting metrics, or consumers might want to trust "any JCHAO-certified hospital worldwide" when sharing emergency PHR information.

Well, as it turns out, we already have a technical model that supports the range of scopes of trust - the certificate authority hierarchy model that drives commerce on the Internet today. Why not allow any self-proclaimed authority to issue certificates to healthcare entities, and have those entities present them on the NHIN? This allows for a full and complete range of trust, with different authorities representing different certifications, obligations, promises, and expectations - just like the real world.

By using standard certificate models from the get-go, we can start with point-to-point trust, and expand into more and more powerful use cases as authorities emerge (I would love for HHS to stand up the first of these). We get the best of all worlds --- exchange now, with a path to make it better over time.

This just feels right... and easy. Next!

I have been really excited over the last few weeks as our national discussion around healthcare standards and data exchange have taken on a real world quality that has felt lacking in the past. But change is hard to make stick, and John Halamka's blog today about audit trails is a reminder that we all need to stay engaged in the process.

To be clear, I'm not going negative here --- John and the committee are being super-thoughtful and we completely need to have the discussions about, for example in this case, what level of auditing is required to enable useful exchange.

The right starting place for that discussion, though, is to go back to the "start simple" mantra: what is the minimum set of requirements necessary to enable useful exchange? Any given requirement should start with NO and prove its way to YES, rather than the other way around. "It seems useful and doesn't seem that hard to implement" should never be a reason to add a requirement.

I have made a career out of building things that are step in front of what people are asking for. It turns out that the trick to doing this well is to implement things a little at a time - explicitly not trying to solve the entire problem with the first bite. This makes two things happen that otherwise simply don't:

1. You empower people to see around the next corner. By delivering a concrete, real first version, it helps people "get the point" - so you can have an intelligent conversation with them about the next one.
   
   
2. You always (always!) learn unexpected lessons about what is really important by living in the real world. Things that seemed hard turn out to be easy, things that seemed important turn out to be irrelevant, and every combination thereof.

The way I measure success in these situations is when people tell me that something I've built is "totally broken" because it needs to be improved or extended --- especially when I can say, "Yep, here's the roadmap we've been thinking about for that." This outcome means that I have made it around the first corner --- people now "get it" and understand the value of something new.

Data exchange in health is going to be the same way. The best, most important, incredibly great thing we can do is get real data moving for real patients. THAT legally-tractable audit trails exist is critical. But HOW those audit trails are captured and formatted is simply not a prerequisite. All we need to know is --- per John's option #3 --- if there is a breach, investigators will have the raw material they need to conduct an investigation.

If we do this --- I will with some admitted arrogance predict the pattern that will ensue. First, we will get to real exchange more quickly, and we will see real benefits to the nation. Second, people will start saying, "This sucks! Every time I have to coordinate audits it's totally manual --- why can't we have some kind of integrated repository?" And that argument MAY justify the costs of consensus and implementation. At the very least, we will have more information in front of us to make the call intelligently and an easier discussion about what the right approach is.

This is a drum I will keep beating - start with NO, implement incrementally, and keep learning. There will always be folks wanting to add more to the pot, using "not that hard" and "solve it now so you don't have to revisit it later" as their arguments. All advancement leaves a little legacy and the world is always a little messy - that's OK!

I spent Thursday last week at the HIT Standards Committee's inaugural "Implementation Workgroup" meeting in Washington DC. The purpose of the meeting was for the committee to hear perspectives from folks who are "on the ground" and could offer real-world perspectives on the pros and cons of what HITSP has done to date --- to help guide its work going forward. I participated on a panel of five vendors that included HSG (me), Surescripts, RelayHelath, eClinicalWorks and Orion Health.

To set the stage clearly --- I have not been a huge fan of the HIT work coming out of the government and its advisory bodies. This is not because I don't think standards are a good idea, or because I think the committee members aren't smart and dedicated folks trying to do good work --- they clearly are both of those things. I just feel strongly that standards emerge when they are needed and desired - and that without those two ingredients they are at best irrelevant, and at worst become inadvertent obstacles to the kind of innovation they were intended to accelerate.

The reason we don't have greater adoption of healthcare standards is simple:  the use cases they enable aren't sufficiently compelling to the parties expected to use them. ARRA dollars will have some impact on the motivation problem for sure, but that gravy train can't last forever - so we'd better be thinking beyond it if we want changes that stick.

Frankly, I felt like my testimony was only so-so. I feel pretty good about my written comments, but in the compressed timeframe of the meeting itself I didn't articulate my points as well as I expect of myself --- kind of a bummer. What I tried to say was: HITSP has at least one great success, namely the CCD. It works because it is a relatively simple, inclusive document that people understand and have real uses for. Let's focus on the lessons we can take from this example, and trim away all of the other noise.

Kind of the same arguments we've been having for a long time. Lots of exhortations to keep things small and simple, but without the specifics needed to make that advice actionable. Despite many examples of good insight throughout the day, as things wound down I was not feeling optimistic about any real change coming out of the discussion.

However, right at the end of the meeting, I heard something that got me really excited - it made my trip worthwhile and I am hoping that it just might be the start of a real shift. The specific comment came from Wes Rishel, but it was the culmination of a thread that started early in the day with Adam Bosworth, and popped up throughout the proceedings in comments from David McCallie and others.

Wes' statement was this (not an exact quote but very close): "We need to get SDOs out of the business of creating HTTP." The reference to HTTP started in the context of discussion the success of the web, when Adam made the observation that a key to this success was a clear separation of content (HTML) from envelope (HTTP) - meaning that each of them could evolve and innovate separately from the other - and that the utility of each was maximized. For example, we have been able to add security models on top of HTTP with no dependencies on HTML. And HTML has seen great use beyond the world of HTTP, for example in many TV set-top boxes that communicate over proprietary cable networks.

Even beyond the separation, the observation was made that transport simply is not a healthcare problem. Back when HIT standards bodies got their start, transport had to be built in from the ground up. This is no longer the case, but too much of the standards discussion is still based on whether we should use SOAP or REST or EDI or who knows what to move the data around - all the layers get conflated and create unwieldy and overly-restrictive end products.

This kind of thing has been said many times before --- it was in fact the real nut of I was trying to say in my own testimony. But I had never seen it articulated so clearly by members of the committee, and honestly I had never seen it that clearly myself. When I dig into the HITSP standards, the parts that drive me crazy are all about transport, needlessly-restrictive limitations on technology choice and other conflations obscuring the specific purpose of the standard.

So what does this mean? Well, maybe nothing --- but I am an optimistic guy and would love to see positive outcomes from the investments we are making as a nation in HIT and HIT standards. If just that one observation from yesterday sticks - we get out of the business of creating "HTTP" - we may really get somewhere.

People ask me a lot why I came back to Microsoft after being away for so long. The answer is pretty simple: I don't believe there is anybody in the world better positioned to make a real difference in the world of healthcare technology.  And that's about more than just a dollar commitment. Microsoft has the right DNA, breadth, patience and audacity to create a portfolio of products that span the entire industry - so we can deliver real end-to-end solutions.

Once you've got that "palette" of tools to work with (and it's taken awhile for us to get to the point where the maturity is there to really leverage them), you can do amazing things really quickly. That's when things get truly awesome.

Recently we had the opportunity to demonstrate how this can work by playing a small but real part in the national effort to help deal with the H1N1 virus that seems poised to be a real challenge for our public health system.

Researchers at Emory University have been working for some time on an algorithm called SORT that is intended to help people self-triage when they are worried about flu symptoms. In creator Dr. Arthur Kellermann's words:

By providing an at-home tool that can help users evaluate whether they need to see a provider before they head to the hospital, we can encourage those who are severely ill or at risk for serious illness to contact their doctor, and reassure everyone else that it is safe and prudent to recover at home. This will reduce the number of people needlessly exposed to H1N1 influenza in crowded clinic and ER waiting rooms, and allow doctors and nurses to focus their attention on those who need them most.

Microsoft has partnered with Emory to make this self-assessment tool as widely-available as possible by launching the H1N1 Response Center. I'm not going to rewrite the press release on the Response Center here; instead I'm going to talk about all the pieces that came together to make it happen.

The Response Center has three parts to it; each serving a different purpose:

1. The Self-Assessment website. The anonymous survey is hosted on our cloud-based computing platform Azure. While the site itself is relatively simple, running it on Azure provides us virtually unmatched scalability - so the site will stay available even if it experiences heavy "burst" traffic due to specific news events or other spikes.
   
   
2. For individuals who decide to go to a provider for care, they can use our simple "prepare for visit" HealthVault application to ensure that they have all the information available to receive the care they need. Using this free application also helps populate a personal health record that can be used on a go-forward basis to help coordinate care using a wide variety of personal health tools and services.
   
   
3. On an opt-in and optional basis, we invite people to submit the results of their assessments for use in public health research and surveillance. This information is sent through an Azure Queue to a hosted instance of the Amalga 2009 Unified Intelligence System and the aggregate information is made available on a real-time basis to qualified organizations. That's worth saying twice - the information is made available on a real-time basis - and visualized in the Amalga UIS client application that allows rich analysis as well as integration with other tools. [Note: if you are a researcher who would benefit from access to this information, please contact me using the form on this blog or by sending email to hvbd@microsoft.com]

Here's a simple diagram of how it all fits together:

Azure-based self-assessment

At first glance the assessment site is pretty simple. In addition to some educational content from the CDC, primarily it's a sequence of questions that walk the individual through the decision tree created by Emory, resulting in an assessment as to the best course of action based on current understanding. Beneath the covers, though, a few interesting things are at work.

Most important is the scalability that running on Azure delivers. Microsoft has created an enormous computing "fabric" on which applications can be deployed. Once in the fabric, capacity can be dynamically increased and decreased as needed to support traffic bursts or lulls. This is a huge advance in hosting technology, because it is of course exactly during burst events that the applications are most needed. Very few companies today are in a position to deliver this level of resiliency.

Because "best practices" for self-assessment are also evolving rapidly as researchers learn more about the virus, the assessment site has been engineered to allow changes in the algorithms to easily flow into the site with minimal recoding.

Finally, the site supports the presentation of locally-relevant guidance in addition to its topline assessment. This can be used, for example, to direct individuals to local hotlines or triage centers to receive care, or to facilities where wait times are lower. We are working with a number of organizations to begin populating and maintaining this content.

From within the assessment site, users have the option to "prepare for a visit" with a HealthVault application and/or contribute their survey data for public health research and surveillance. If they choose either of these options, their information is sent to an Azure Storage Queue where it will be picked up by the appropriate target. Azure Queues make it super-easy to move information between loosely-coupled systems like these in a reliable way --- I've been really impressed with the performance of this stuff.

HealthVault "Prepare for Visit" Application

I'm not going to burn a bunch of words talking about HealthVault in this post --- suffice to say that it's our uber-awesome personal health platform; you can get a quick overview by skimming through my Nickel Tour.

What is interesting about our "prepare for visit" application is that it demonstrates how it's not a single "PHR Application" that's important. What transforms personal health is the data platform underneath, enabling a ton of special-purpose applications that help people accomplish specific jobs. We were able to create a very simple application tuned to one purpose - create a printout to bring to a doctor for a flu visit - and stand on the shoulders of all the other applications out there than make it easy to enter or (even better) automatically import medications, allergies, immunizations and so on.

I am confident that this new targeted application will introduce a whole new set of individuals to HealthVault and the value it offers --- goodness not just now but for the future.

Amalga UIS for Research and Surveillance

UIS is the core of so much of what we do within the Health Solutions Group. Originally created as "Azyxxi" within the Medstar network of hospitals, it is a product that can be hard to describe in a few lines. Perhaps the easiest way to describe the product is a tool for "real time business intelligence" - but it's really that and a lot more.

This is the only part of the H1N1 project I can actually take personal credit for! Once in awhile they actually let me do real work around here, and I had a great time building the parsers and views to support public health research and surveillance based on the assessment data people have chosen to contribute.

After the Azure site drops assessment information into its Azure Queue, a simple Windows service running in our data center pulls the messages out and submits them to the Amalga parsing engine. Here, the messages are transformed into a number of useful forms - ranging from granular detail views to a number of different aggregations (based on date, region, etc.). This all happens in real-time --- no batch processes to be found here! --- and the information is made directly available to researchers through the UIS client.

What is most remarkable about Amalga in cases like this is its ability to evolve and adapt as new needs emerge. For example, over the weekend it became clear that to identify spikes in particular regions we were going to need some transformations that I had not anticipated. In most systems, this kind of rework is cumbersome at best - in Amalga I was able to simply add a new "parser" and tell it to re-run over the historical message queue; just five hours after identifying the need the new view was available for use - like going back and rewriting history.

I'm going to be writing a lot more about Amalga in the next few months; it is a part of the palette I haven't spent enough sharing with folks here on the blog.

Wow, this entry got really long.

At the end of the day -- the point is, we saw a need and had a ton of great "parts" at our disposal we could snap together to deliver a solution - from concept to launch in just twenty-eight days. THIS is why I'm back at Microsoft, and it is a pretty wicked place to be. So what's next?

"Broken Windows" theory says, in a nutshell, that letting little things go can lead to big problems:

[I]f a window in a building is broken and is left unrepaired, all the rest of the windows will soon be broken...one unrepaired broken window is a signal that no one cares, and so breaking more windows costs nothing. [James Wilson & George Kelling, The Atlantic Monthly, March 1982]

This idea was all the rage in the mid-80s, and led authorities in New York and other cities to institute wide-ranging "cleanup" programs and crack down on minor infringements like subway fare-dodging. There is a ton of debate as to whether the subsequent drops in crime rates could really be attributed to these efforts - but it seems clear to me that there's something in there that makes sense.

As it happens, I was reminded just how universal "broken windows" really is a few weeks ago. As my three loyal readers may remember, early last year I embarked on a quest to lose twenty-five pounds. By counting calories, sticking to an exercise program and tracking my progress with HealthVault, I was able to achieve my goal in June. All through the rest of 2008 and into the first part of this year, I kept track of my weight, and pretty easily stayed in my target band of 160-165 lbs.

Then my scale broke.

This did not seem like a big deal. My weight had been stable for almost a year, and I knew what I could eat and what I couldn't. I was still running regularly, so I just didn't worry about replacing the scale.

I think you can guess where this is going.

Without that little digital reminder every morning, little by little my broken windows started adding up. Didn't have diet soda in the house --- one regular Coke won't hurt. Don't have a treadmill in the hotel --- I'd really rather not run outside in the drizzle, just this once. Hungry on the plane --- need to eat, guess that hamburger is my only option. And thus it begins --- once I got used to having one cookie with lunch, having two didn't seem like much of a change....

Fast forward three months, when my wife decided she wanted to lose a bit of weight, so she got a new scale. Holy crap! I had popped up to almost 169 lbs. Well, if I'm really being honest it wasn't so much "holy crap" --- I knew that I was gaining, I just was able to effectively ignore it because I wasn't measuring on a regular basis.

So what happened? I started weighing myself again, every morning, before I got into the shower. I didn't really make any systemic changes in my behavior; I just started noticing what I weighed and how much I was exercising. Six weeks later, and I'm back in business --- just broke the 165 lbs mark again. Woo hoo!

It continues to amaze me how I have to relearn the same lesson over and over. Measure, measure, measure - and don't let it start slipping, because those broken windows add up fast. Maybe this time I'll beat the Vegas odds and it will stick with me.

Over Labor Day weekend my kids and I took off for an overnight hiking trip to Ingalls Creek, in the Alpine Lakes Wilderness just south of Leavenworth. After one of the most arid summers in Washington history, we managed to pick the one weekend where it rained like nobody's business. We got well and truly soaked.

A bit of proud papa here, so forgive me for a second. My kids pick at each other just like all brothers and sisters do. But beneath all that, they are growing up to be super-nice people. When Alex was getting cold and miserable on the trail, Connor quietly guided us into camp just a little bit early so she could sit down. Later that evening when Connor was starting to shiver, Alex put her arm around him and distracted him with questions about his new class at school while I got a fire started.

This stuff is important to me - the world is too often an angry place, and I appreciate it when folks demonstrate that they care about the people around them. This is the same thing makes health a really nice business to be in.

For example --- I spend a lot of time working with people from Seattle Children's Hospital. Most of our meetings take place away from the actual hospital, but occasionally we end up there for one reason or another. It is remarkable to watch how every Seakids employee acts when they're there - if we're in an elevator and a patient needs to get in, we get out mid-ride and take the stairs the rest of the way. If a patient asks a question, everything stops. It's really impressive.  

Another example --- we just hired a new architect on the team; a super-smart guy who has been in healthcare IT for a long time. I've watched him in meetings a few times when silly arguments start back and forth. He just pulls out the big gun: "Does this help doctors fix sick kids? Yes or no? That's why we're here."

What I've learned over the last few years is, almost everybody who works in health does so because they care and they want to make things better. We all pick at each other sometimes (I'm sure there are some Microsoft folks laughing at the irony of me talking about being nice), but at the end of the day, knowing why we're here makes up for a whole lot of frustration.

Hope you all had a great Labor Day as well.

Once in awhile I get a glimpse of what healthcare is going to look like in a few years - and it is super-awesome. That happened the other day -- I got to experience what happens when you take two really great consumer health ideas and loosely couple them through HealthVault.

MyMedLab

First of the pair: MyMedLab. I first learned about these guys late last year when they presented at Health 2.0. What MML does seems pretty simple: they let you order and pay for your own laboratory tests. You pick the tests you want, give them a credit card, go to a local Labcorp collection facility, give up the blood or other samples, and within a day or so --- you get the results. And to boot, they have done a fantastic HealthVault integration using our "dropoff / pickup" model. Just by checking a box during the checkout process, you can have your results available for use in other HealthVault applications.

The experience is phenomenal - especially when you compare it to the typical pattern. Try to get an appointment, sit forever in the waiting room, see the doctor for ten minutes and have her write the lab order, go in for collection, wait for the results to get to your doctor, then to the nurse, then play phone tag with the office as they try to catch you in person to give you the results. Cray-zee.

But wait, don't you need a doctor to decide which tests you need to get? Well sure, sometimes things are complicated. But much of the time they are not. I wonder if I have high cholesterol, or should be thinking about diabetes, or perhaps wonder if the fatigue I'm feeling is a thyroid issue (well ok, pretty sure it's not the menopause thing in my case). What I need is the test - and there is no reason for a doctor to gate my access to it.

Keas

Interpretation - or rather understanding the implications of the results - that's another matter and it is important. This is where the second of the pair shines: Keas, the new brainchild of Adam Bosworth. Keas is still in limited beta, but I got excited enough that I asked for Adam's OK to talk about it here.

Keas is about care plans - capturing clinical expertise in personalized "rule sets" that can help guide individuals along their journey to manage chronic conditions, stay healthy and fit, lose weight, pretty much anything. The core drivers behind these rule sets are laboratory values and measurements, and guess what, they've connected to HealthVault as well - so my MyMedLab test results flow right into the application.

With that data, I can immediately see a ton of information to help me understand my results and put them into context. For example, my HDL cholesterol is normal --- not optimal, but not a matter for significant concern either.

Not only do I get access to all of this information, I can enroll in the Keas "Cholesterol Control Plan" and get tips and tools to help me move the number into the "optimal" range. So Keas becomes my everyday management tool, and every couple of weeks I can refresh my results by visiting MyMedLab. Bingo bango, I have a super-high-quality end-to-end disease management program.

Creating plans like this is a big task across a bunch of dimensions. We know because we're doing similar work with the Mayo Clinic as part of the Mayo Clinic Health Manager - most clinical "best practices" have never been codified to the level necessary to really be computable and capture all of the subtleties that make the difference between solid recommendations and useless platitudes. Adam talks about this as the "recalc engine for health" --- he and his team are great folks to build it.

Better Together!

At the end of the day --- the key thing to realize here is that MyMedLab and Keas know nothing about each other. One is focused on making it easy to get lab results, and the other is focused on turning lab results into valuable information and recommendations. But because they both talk to HealthVault, they link together without doing any extra work - and the combination of both is far better than either alone.

This is what we mean when we talk about the power of an open ecosystem, folks!

This is awesome. But it does create a challenge around providing great support to that large and fast-growing developer community.

Our MSDN site has always been a pretty great resource, and the good folks working on developer support have created a ton of content to help HealthVault developers be successful. Eric and Vaibhav have done great things with their blogs, and posts to our developer forum tend to get answered pretty quickly --- although we can't take all the credit for that; we owe a huge debt of thanks to Raj of Get Real Consulting, who by now knows more about HealthVault that most of us on the team (by the way, if you're a HealthVault developer and you're not using Get Real's X-ray utility, you are really missing out).

Still, there have always been cases where partners have needed timely, specific help on issues that just require one-to-one interaction. The volume of these keeps going up, and we've gotten to a point where we really can't provide the level of service we want by calling in engineers and developers on an ad hoc basis. So - time to grow again!

We now have a team of dedicated HealthVault developers who are ready to help with one-on-one troubleshooting and guidance on building HealthVault-integrated apps. This past weekend we launched a new email-based HealthVault Developer Support offering. Here's how it works:

• Go to http://support.microsoft.com/ or the "Support" tab on our MSDN site.
• Submit your question via a web form (English only for now).
• One of our developers gets back to you over email within one business day.

When we exit Beta (sometime before the end of calendar 2009), there will be a $99 per incident charge for this premium support option, but until then it is free. It's a great complement to our existing, community-based support options --- use it for confidential questions, or if you need a deeper discussion than you've been able to have on the forums.

Just as cool, we're starting to see third-party training options become available as well. During the Connected Health Conference in June, I had the opportunity to meet David Platt of Rolling Thunder Computing. David has been writing about and teaching .NET and other technologies for a long time, and has recently created a full three day HealthVault training course that he offers at his location or yours. I haven't sat through the training, but David is clearly a smart dude and talented teacher --- and the syllabus looks great. The next scheduled class is next month, September 23-25, and you can learn more at http://learnhealthvault.com/. If you attend a session --- leave a comment here and let me know what you think!

What a great time to be working on personal health. Progress like this reminds me that Microsoft really is built on developer DNA --- we are only successful when our developer community is successful. We still have holes, of course (more sample code and shared SDK controls, anyone?)  --- but we are getting there. I'd love to know what you think we need to do next to keep the momentum strong.

I've copied below a note I just sent to some of the good folks responsible for setting policy around which standards will be considered appropriate for meaningful exchange of clinical summaries. As I've said many times before, I believe that annointing just one standard misses the point -- the hard part is collecting the information to share in the first place. We should be encouraging anything that accelerates that task --- and leveraging all of the work that has already been done against the problem. Once information is available, transforming it between near-equivalent standards becomes a much smaller task.

If you have thoughts of your own --- in support of or argument against my thoughts --- please chime in --- it's important!

Colleagues ---

My purpose in writing is to provide some input "from the field" as you and your committees dig into the hard work of making "meaningful use" a concrete and measurable concept. In particular, I am hopeful that as you consider standards for the exchange of summary health records, you sanction and approve use of both the HL7 CCD/C32 and the ASTM CCR formats. I've also posted this note to my public blog to help encourage more comment and discussion.

Just three and a half years ago, I had very little experience in the healthcare domain --- which has proven to be both a challenge and a benefit. The challenge is of course obvious, but the benefit is perhaps more subtle. Faced with the task of exchanging summary information with the myriad of diverse players in the healthcare ecosystem, we saw the incredible variance in capabilities from system to system, and made an explicit choice with HealthVault to "take what we could get." Rather than forcing our partners to adapt to HealthVault, we asked them what they could send, and worked internally to harmonize and reconcile the information we received.

This is the same integration philosophy that the founders of our Amalga "Unified Intelligence System" took in building a system that can provide comprehensive views of patient data within an enterprise or group of enterprises. But unlike the utterly cacophonous world that Amalga works in, with HealthVault we have found that the world is converging on just two standards for summary exchange: the ASTM CCR and the HL7 CCD (in particular the more structured C32 variant).

Most importantly, it is our experience that neither of these two standards is "winning" over the other in the marketplace. Instead, for many legitimate reasons, different organizations have chosen to use one or the other in what seem to be near-equal measure. The good news is, this works just fine! It is simple for point-to-point or small-group exchanges to choose the format that works for them --- both easily represent the key information necessarily for summary exchange. Further, when connecting more diverse groups that may represent mixed use, systems and technology have emerged that make it easy to transform summaries as necessary to support heterogeneous exchange. HealthVault is just one example of such as system, where in the personal health space we accept both CCR and CCD, and provide tools for our users to reconcile information into a common record (I've included a few links at the end of this message where you can read more about HealthVault's use of the two standards).

At the end of the day, what we've learned is this: the hard work is in collecting complete and accurate summary information in the first place. Many organizations and vendors have been hard at work for the last few years building the code required to do that well. It is far more important to "meaningful use" that we leverage all of that existing work than it is to force it into any one XML standard --- especially when the market has proven that translations between these formats when required are well-understood.

I believe that the best choice to maximize real data exchange is simply to endorse both formats as acceptable for representation and exchange of clinical summaries.

I hope you find this input useful; I am of course available to clarify or expand upon my thoughts at any time if needed.

Related posts:

• http://blogs.msdn.com/familyhealthguy/archive/2008/07/13/again-with-the-standards-thing.aspx
• http://blogs.msdn.com/familyhealthguy/archive/2008/10/23/awkward-turtle.aspx
• http://blogs.msdn.com/familyhealthguy/pages/the-healthvault-nickel-tour.aspx