Family Health Guy

Hey -- was that just an HIT Standards breakthrough?

seannol — Sun, 01 Nov 2009 06:48:00 GMT

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.

H1N1: Painting with the HSG Palette

seannol — Tue, 13 Oct 2009 04:50:00 GMT

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:

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.
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.
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 and Broken Scales

seannol — Tue, 06 Oct 2009 22:55:00 GMT

"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.

A Nice Business

seannol — Wed, 09 Sep 2009 05:51:00 GMT

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.

MyMedLab + Keas + HealthVault = Awesome

seannol — Wed, 26 Aug 2009 23:04:00 GMT

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!

Scaling up our support options

seannol — Wed, 05 Aug 2009 08:51:00 GMT

As it turns out, there are a ton of people working on HealthVault-related projects. Hospitals, labs, payers and other health systems sharing data with their patients; pharmacies helping to manage medications; direct to consumer startups building innovative tools; device manufacturers participating in the "Works with Microsoft HealthVault" program; academic institutions doing research --- the list has grown way more quickly than we expected when we started out.

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.

Even more on CCR "vs" CCD --- we don't need to choose!

seannol — Sun, 26 Jul 2009 18:54:00 GMT

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

Self-Evident

seannol — Mon, 22 Jun 2009 22:15:00 GMT

If you've ever had to work through even a slightly complicated encounter with our health care system - you know what it's like. You become a combination archaeologist, file cabinet and pack mule, begging providers for copies of your own images, lab results, medication lists, and encounter notes, then trying to make sure they're in front of the right people when decisions are made. Really, it's just nuts.

Tools like HealthVault help solve part of this problem - we are working hard to build connections to all of those places where your data lives, making it easier to create a comprehensive data asset and share it with all the members of your extended care team: providers, family members and, increasingly, innovative consumer services that use the power of software and social networks to create insight.

But in order for software to matter, our culture and attitudes need to change too. As I travel around the country working to help organizations share data with individuals, I consistently hear objections that reflect that challenge, even though HIPAA already says they are required to share on demand:

People won't know what to do with this information; they need providers to filter it for them.
If people see the raw data, they'll overwhelm providers with irrelevant questions.
Sharing information could increase liability risk.
Misuse of "their" information could damage a provider's brand.
Sharing information gives away a competitive advantage to a provider's business.
... and more.

Right now, there are tons of policy "concrete" being poured into our healthcare system, thanks to ARRA and President Obama's push for healthcare reform. Before that concrete hardens, it is critical that we firmly establish complete access to one's own health data as an unassailable ethical and moral human right.

This is why I was so excited when I was invited to join the group of thought leaders across healthcare working to establish a Declaration of Health Data Rights at http://www.healthdatarights.org/. The text of the declaration is clear, appropriate and extraordinarily important to the advancement of effective care in our country and beyond:

A Declaration of Health Data Rights

In an era when technology allows personal health information to be more easily stored, updated, accessed and exchanged, the following rights should be self-evident and inalienable. We the people:

Have the right to our own health data

Have the right to know the source of each health data element

Have the right to take possession of a complete copy of our individual health data, without delay, at minimal or no cost; If data exist in computable form, they must be made available in that form

Have the right to share our health data with others as we see fit

These principles express basic human rights as well as essential elements of health care that is participatory, appropriate and in the interests of each patient. No law or policy should abridge these rights.

Microsoft and I wholeheartedly endorse this declaration and are proud to be part of a growing community that recognizes its importance. If you would like to add your voice to ours, you can get started by visiting http://www.healthdatarights.org/.

Self-evident indeed.

The Worst Idea Ever

seannol — Tue, 16 Jun 2009 08:41:00 GMT

One day when I was about fourteen years old, I bought a bunch of fireworks (rockets mostly) from that shady guy who roams the halls of every high school selling contraband. I went over to my friend Don's house in the afternoon and we really wanted to shoot some of them off - but it was raining outside, and we didn't want to stand outside getting wet.

"I have a great idea," I said. "We can open the windows of the dining room and launch the rockets from INSIDE the house - that way we'll stay dry." Pure adolescent genius, I tell you.

Now, you may have a sense of where this is going. Suffice to say that we spent a couple of hours desperately trying to get exhaust marks and the smell of sulphur out of Don's mom's super-fancy Oriental rug, and I was really glad that we tried this at his house, not mine. Looking back over the last forty years of my life, I have often referred to this as the Worst Idea Ever.

But today the great indoor fireworks episode has competition, in the form of a truly insane HIT bill up for consideration in the New Jersey State Legislature. Bill 3934 would make it ILLEGAL to sell any "health information technology product" that is not certified by CCHIT:

2. (New section) a. No person or entity, either directly or indirectly, shall sell, offer for sale, give, furnish, or otherwise distribute to any person or entity in this State a health information technology product that has not been certified by the Certification Commission for Healthcare Information Technology.

As used in this section, "health information technology product" means a system, program, application, or other product that is based upon technology which is used to electronically collect, store, retrieve, and transfer clinical, administrative, and financial health information.

b. A person or entity that violates the provisions of subsection a. of this section shall be liable to a civil penalty of not less than $1,000 for the first violation, not less than $2,500 for the second violation, and $5,000 for the third and each subsequent violation, to be collected pursuant to the "Penalty Enforcement Law of 1999," P.L.1999, c.274 (C.2A:58-10 et seq.).

Frankly, I am just too stunned to really say much of anything about this disaster of a bill. It is actually difficult to think of another action that would be more effective at screwing up healthcare.

Look --- there are plenty of real debates to be had around HIT. I believe the evidence does not support the idea that CCHIT certification has or will stimulate adoption, but there are reasonable arguments on both sides. Happy to have that conversation. But there is simply no sensible position that would criminalize innovation in an industry that desperately --- desperately --- needs new ideas.

Please, New Jersey, do your citizens a favor and just make this go away.

We never were able to fix the carpet.

Continua in da house!

seannol — Thu, 11 Jun 2009 09:25:00 GMT

Thursday is the first full day of the 2009 Microsoft Connected Health Conference here in Bellevue ... there were a few events today, but things really get underway tomorrow at 9am with Peter's keynote and an opening panel including Uwe Reinhardt, David Kibbe and Mike Leavitt (Mike, not Mark, so we won't likely see an onstage rumble). I'll be wandering around all day, except for a presentation for our Amalga customers in the afternoon and a Q&A panel just after that. If you see me wandering around avoiding eye contact with strangers, say hello!

Anyway, I wanted to call out one session tomorrow that I'm particularly excited about:

Learn how Continua-compatible devices can work with HealthVault and what it might mean for your development efforts. ---Jesse St. Marie, Senior Program Manager, Microsoft Corp.

Jesse is our go-to guy for devices, and has been working on this for some time. At this session attendees will see a real, live, Continua Certified^TM fingertip pulse oximeter connect through a PC to HealthVault Connection Center and upload readings to a HealthVault record. It's not production-ready yet, but it's completely real.

Let's say that again, because it was really fun the first time.

We will show a Continua device sending data directly to HealthVault.

We've said again and again that what Continua is doing is complementary, not competitive, to what we're doing with HealthVault - and that integrating devices is the thing to focus on, not "joining Continua." Now that Continua certified products are entering the market, we're doing the work to get them hooked up, just like we promised.

We're simply not out to create and define standards - that is for other folks to do. We are about creating a connected ecosystem for health, embracing all of the standards that are important to making that a reality. Continua is on a path to be a meaningful part of that ecosystem.

This is great news for everybody --- HealthVault users will have more options; device manufacturers can choose to build products in whatever way works for them; and both Microsoft and Continua can (maybe) stop answering questions that just don't matter.

Good times.

You put your right HIPAA in…

seannol — Wed, 03 Jun 2009 08:00:00 GMT

Early last May, I posted an entry that described our position regarding the relationship of HealthVault to HIPAA. In short, our interpretation was that HealthVault did not fall under the definition of a Covered Entity or a Business Associate as defined by the legislation. Further, it seemed clear that HIPAA was simply not intended to cover services like HealthVault that provide tools to help individuals manage copies of their own health information. Pretty simple, really.

Fast forward about a year, and "pretty simple" just wasn't good enough for the well-meaning folks in Washington, DC. When they sat down to reform healthcare with the ARRA bill, things got a bit muddled up. Did anything really change that would affect our position? Unfortunately, the answer is really "nobody knows."

You simply cannot imagine how many hours I have spent in small conference rooms with no windows listening to experts argue this back and forth. Really.

Here's the thing: this renewed atmosphere of ambiguity and uncertainty risks slowing down the important work we all are trying to get done - helping individuals get and stay healthier by collecting, sharing and leveraging their own personal health information - connected to their trusted providers.

So we decided to take a new look at the legislation. And when we did that, we realized that it really didn't matter how we are technically defined. As we have said from day one, we operate the HealthVault systems far beyond the baseline privacy and security measures required by HIPAA anyways. And further, we can sign "Business Associate Agreements" with covered entities that want to interact with HealthVault, without in any way restricting our ability to put consumers in control of their information. To be clear --- we can and will, without modification or compromise, continue to stand behind our privacy statement and service agreement.

Which brings me to the real point here. We are now prepared to sign a Business Associate Agreement with any covered entity that feels it is an important part of their responsibility under the HIPAA legislation. We have worked hard to create the text of that BAA, and are committed to being open and transparent about exactly what it contains. In fact, it is posted online for anybody to review here.

To date we have spent far too much time explaining to covered entities why we did not need a BAA between us. Going forward, we just don't need to have that discussion. This is a really, really Good Thing.

Onward!

Sweet Opportunity for Health Devices

seannol — Sat, 23 May 2009 03:02:00 GMT

As I posted about a few days ago, we're gearing up for the Connected Health Conference, happening here in Bellevue from June 10^th through 12^th. It looks like a really strong event, with an eclectic mix of participants and speakers showing off real-world evidence that the future of healthcare is well on its way. If you'd like to join us, just use the code "CHCREG" to register online.

I learned yesterday evening about another fantastic program we've got going at the conference - the HealthVaultDevices@BestBuy "side event." We've teamed up with Best Buy to invite anybody building connected health or wellness-related devices to pitch them to a panel of executives from both companies. The panel will select the most promising devices to discuss collaboration opportunities with Best Buy - the largest consumer electronics retailer in the United States. Not too shabby!

I understand that we've got a bunch of really cool companies signed up already - are we going to see yours? Having an existing connection to HealthVault is an advantage for sure, but not required. I'm going to try to sneak in and watch.

Full information and the signup form can be found here.

Another promise delivered

seannol — Tue, 19 May 2009 09:12:00 GMT

I am super-excited to say that, as of last week, we have officially released the HealthVault service specification under the Community Promise. This means that anybody who wishes to create and operate their own version of the HealthVault service is free to do so. We have documented the interface at a level sufficient for re-implementation, and we grant an irrevocable, compensation-free license to use any Microsoft patents required to execute the specification.

This is a big deal -- the last of three key initiatives we undertook more than a year ago to ensure that developers who build on top of HealthVault can be confident in their investment. We are not going away. But even if we did, or if for any reason a developer decided they no longer wanted to connect to "our" HealthVault, there is a realistic path to run against another implementation, with just a configuration change.

Will there be other implementations? That's up to the market - we've made it possible.

When we first announced our intent to release the specification last April, we thought it would be published a lot sooner. As we've followed the long path to get it done, I've learned a ton about the internal processes and gates here at Microsoft that help protect our intellectual property. The company takes this incredibly seriously - and rightly so, as IP is our only real asset - so releasing it so freely is a huge step that required explicit approval at the highest levels of the company. It speaks volumes about our approach to the health market and our ecosystem partners.

We also originally planned to use the Open Specification Promise, and ended up using the similar Community Promise instead. Why? Because the CP allows us to limit the license to the healthcare domain, which seemed to make a bunch of sense. Other than that, basically the same deal.

So whether you need an open source library to work with HealthVault, want to see or build upon the complete source code tree for our .NET SDK, or want to go all-in and create your own version of the HealthVault service, it's all good.

Yet another barrier knocked down, and yet another proof point that Microsoft is committed to do what is necessary to help spur real, fundamental change in our healthcare system.

Sitting in a random hotel in Albany at 2am - having missed seeing my son turn two double plays in one game because I was on the plane to get here - this healthcare thing can seem like a long slog. It is just awesome to have things like this to get excited about and be a part of. Wooooo hoo!

I love it when a plan comes together

seannol — Fri, 08 May 2009 09:23:00 GMT

You know, I'm starting to think we just may be onto something with this whole HealthVault idea. This afternoon I was talking with a guy who's writing a pretty broad piece on consumer-driven healthcare, and as I was running through all of the accomplishments of just the last few weeks ... I managed to get myself all worked up and excited:

April 7, New York, NY: New York Presbyterian hospital launches mynyp.org, a robust patient portal powered by HealthVault and Amalga - real patients receiving rich visit summaries they can share with primary and referring providers.
April 21, Rochester, MN: The Mayo Clinic launches Mayo Clinic Health Manager powered by HealthVault - extending the reach of Mayo's clinical expertise to family health managers across the country.
May 6, Toronto, ON: TELUS announces they have licensed the HealthVault platform to provide a consumer-centric health service across Canada - proving that what we are doing is meaningful not just in the US, but around the world.

And of course, these don't even touch on our enterprise progress, where since HIMSS 2009 we have launched not only Amalga UIS 2009, a major revision of our data aggregation toolkit for healthcare, but Amalga Life Sciences 2009, a brand new product targeted at bioscience research.

Peter doesn't generally talk much about our products on his blog - but I'm too much of a proud papa to do the same over here. Woo hoo, go HealthVault and Amalga!

Which brings me to the real point of the day. Next month, from June 10^th through the 12^th, we will be hosting the third annual Microsoft Connected Health Conference here at the Meydenbauer Center in Bellevue, and I really hope you'll join us.

Now, I'm not generally a "conference guy" - for one thing I'm just way too much of a social hermit to be comfortable in the crowd, but I also get frustrated listening to what often seem like the same speeches at event after event. From the planning I've seen so far, I'm confident that this isn't going to be an issue at the CHC. The team is working super-hard to put together a program that talks about REAL traction - focusing on how REAL organizations are making progress by using technologies like HealthVault and Amalga. And they're setting up a bunch of formal and informal networking and Q&A time where folks can have real, in-depth discussions around the issues that are helping or hindering that progress - the kind of discussions that you can take back home with you and apply directly to your piece of the puzzle.

My understanding is that I'm on the hook for at least one session and a couple of Q&A panels --- I think it's going to be really useful and a ton of fun. I hope that you will choose to come out and spend some time with us. And if you are there, make sure to say hey if you see me hiding in the corner trying to look inconspicuous.

You can sign up for the conference at the CHC web site, or feel free to use the "email" form at the top right of this page to ask me any questions about the event.

This just in: sharing health data is hard.

seannol — Wed, 15 Apr 2009 07:31:00 GMT

The folks at Google Health have been taking it on the chin this week, after the Boston Globe ran an article about a super-engaged patient named Dave who found a number of pretty nasty surprises when he imported his health information from Beth Israel into Google. From what I have read there were really three key issues at play:

BIDMC is sending condition information based on billing codes. Inferring good clinical data from billing codes is a notoriously tough thing to do - the codes are vague and dated, and it's just assumed that people will jam whatever seems kind of close in order to keep the dollars moving. And at a more basic level, things that get billed are often exploratory - just because I got an HIV test doesn't mean I have HIV.
A lack of proper date tagging resulted in data mush. For example, he received warnings about "critical" medication/condition interactions where the problematic condition was resolved years ago.
Only a small subset of the record was actually transferred. BIDMC has only implemented sharing of conditions, meds and allergies --- so Dave didn't get everything he expected/wanted in the exchange.

People are having a grand time drawing conclusions from all from this, mostly trying to decide "who sucks" --- is it Google, or BIDMC, or the insurance companies, or lousy doctors, or all PHRs? Maybe the government? One guy actually suggests, seemingly in seriousness, that we should all just give up.

Jeez --- settle down, Beavis.

Yes, there is great learning here as to what can be done better --- Dr. Halamka has already posted about steps they're taking at BIDMC to make things better (as an aside, how many other medical institutions out there display this kind of transparency? Kudos are deserved here.). But the reality is, there is a bunch of dirty data out there in the world, and it is being used not just for billing but to make clinical decisions. Providing transparency and letting people see the mess inside --- that is the first real step to getting it fixed.

Anyways, the question I keep getting asked is --- is HealthVault vulnerable to this as well? As is all too often the case, the answer is yes and no. I think we are in a much better position than Google, but we are definitely not completely immune.

The bottom line is, if I authorize a provider to add data to my record, and they add an item that says "Sean has cancer," then indeed my record will say just that. There is no magic truth detector in HealthVault that knows that I actually don't have cancer (nobody would question our business model if we could do that!). And sometimes the data coming from providers --- especially those that rely on billing codes for clinical information --- will be wrong. So what can we do about it?

This is where our approach to data really helps. When we accept information from hospitals and other providers, we almost always get it in the form of a "package" --- either a CCD or CCR document. Within these documents can be many different individual data elements, all bound together as a snapshot of what that source believes to be true at a given point in time. These snapshots remain in HealthVault as distinct items, and can be digitally signed by the creator so recipients can trust where they came from and that they have not been tampered with in any way.

The user then has another choice - they can "reconcile" the package by looking at the individual items and choosing which ones should be extracted into their record. Only those items that the user chooses to copy out become part of their canonical list of conditions, allergies, medications, and so forth. There are a few really nice things about this approach:

Users have a well-defined place to make decisions about what elements they want to accept and which they believe are wrong. Right now our "reconciliation" process is pretty manual, but as we go forward we expect to do smarter things. One great idea that William Crawford put forth was --- in an interface like this, call out conditions that are associated with billing codes with a special warning icon --- to suggest that the user may want to take a closer look at these.
It puts a fence around the "dirty data" problem so that users can benefit from all sources without worrying that their records are going to become polluted with errors.
It turns out that retaining both the individual items and the package can be really useful - for some use cases the package itself is what a recipient really wants. For example, a referring doctor that wants to see the results of a surgery at NYP probably wants the digitally-signed CCR from that visit, not the user's all-up history.

You can see some screenshots and more detail on our reconciliation interface as part of the HealthVault Nickel Tour ... look for the "integrating information" part of the post.

No matter how you slice it, building and maintaining a quality health record is just a tough problem. I spend a lot of time with hospitals and other providers trying to help them figure out how to start sharing data with patients. So I can't help it --- I have to put in another plug here for New York Presbyterian, which launched their new patient portal at HIMSS last week (I am now officially two days late on my tech details follow-up post about NYP ... working on it!).

NYP uses our Amalga UIS toolkit to create a comprehensive, quality "data asset" that is the foundation driving the visit summaries they send to HealthVault in CCR form. Amalga is a really, really neat piece of software --- its sole purpose in life is to collect data from wherever it is in the institution, aggregate it together, and use it to perform real-time or retrospective analysis, drive internal workflows, or (as in the case of their patient portal) share it with other people or systems. Because they put in so much work up front to create a great data asset --- the information that NYP patients receive in their visit summary is really, really impressive and useful.

All up, I am super-glad that we have folks like Dave out there pushing the envelope. I know that the issues he uncovered are only the first ones we'll have to deal with. I think that with HealthVault we've done a good job laying a foundation that has the right fundamentals to help get us through successfully ... but it will take commitment from everybody involved to really make it work. The good news is, the payoff really matters and will totally be worth it.