Family Health Guy

You need a Data Asset -- not a Data Warehouse

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.

Trust is not Global

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!

Starting with "No"

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!

Hey -- was that just an HIT Standards breakthrough?

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

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

"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

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

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

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!

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

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:

1. Have the right to our own health data
2. Have the right to know the source of each health data element
3. 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
4. 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

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!

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…

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

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.