Two months in, and Adaptive Biotechnologies is the most fun and biggest challenge I've had in years. Loving the biotech life and looking forward to sharing the adventure. 

Woo hoo!

In between time relaxing with the family and getting to know all the great kayaking spots around King County this summer, I was introduced to the incredible work and team at Adaptive Biotechnologies and have accepted a position as their CTO starting in a couple of weeks.

In short, Adaptive has figured out how to apply Next Generation Sequencing technology to the adaptive immune system, and can quantify an individual’s “T-Cell Receptor” repertoire at resolutions far beyond what has been possible in the past. The research and clinical potential is just awesome --- for a taste of just one application, check out what they’ve been able to do detecting “minimum residual disease” in lymphoma patients!

I frankly couldn’t be more excited. It’s a great complement to the work I did at Microsoft trying to help people find the right care and make therapies more effective --- at Adaptive I’ll be helping to create fundamentally new types of care. I cannot wait to get started.

WOO HOO!

PS. I will be starting up a new blog under a new tagline once I find my rhythm at Adaptive … I’ll add a link here when that gets going. See you soon!

That sounds really weird to say out loud --- HealthVault has been my life for eight years now (I even have the logo on my car). But it’s the right time for me, and actually a great time for the service as well. HealthVault is in a solid place at Microsoft with an executive sponsor that cares deeply about the mission and business --- it is an inevitability that our consumer-controlled model will win the day. Two years ago I’m not sure I would have had the same level of confidence, but now I can hand it off knowing all is well.

I asked my daughter, who was twelve years old when I came back to Microsoft, what she remembered most about that time --- she said “you got a gift basket with the best summer sausage ever.” I don’t actually recall the sausage. What I do remember is formulating a mission that resonates unchanged even all these years later. I dug these “talking points” out of my archives from HealthVault launch day back in October, 2007:

• We want to deliver technology solutions to help people live better, longer lives by enabling people to make the best health & wellness decisions. We are delivering a consumer-centric platform enabling an environment of new online services to search, securely store and connect people with their health information, putting them in control of  their (and their family’s) health & wellness.
   
• Transforming healthcare is an incredibly complex challenge – one which no single organization can solve alone. It will require the participation of leaders in every sector of the healthcare ecosystem if success is to be achieved.
   
• We’re embarking on this challenge today with other innovative organizations – from leading medical providers, health management device manufacturers, and national health agencies – and we invite the rest of the health industry to join us. 

Sure sounds like HealthVault 2014 to me. Still playing the long game --- but with more than two million users worldwide, hundreds of connected applications and devices, and a clinical ecosystem that is increasingly integrated thanks to Direct, Blue Button and other awesomeness --- we’ve made a ton of progress.

I’m not sure exactly what is next for me. I’m going to hang out for a month or so --- and then who knows, maybe I’ll jump industries again, or maybe not. I’ve been dipping my toes into the world of genetics and biotech the last couple of months … maybe something there? We’ll see.

For now --- a deep and sincere THANK YOU to those of you who have been my partners on this journey. Peter, for creating the opportunity and being the best partner/mentor ever --- I will work with you anytime, anywhere. Steve and Craig, for sponsoring this crazy experiment at Microsoft. Farzad, Todd, Aneesh, David, Wes, Rich and Arien, for finding a way to make government a positive force for change (who would have believed that?). Scott, Mel, Umesh and Steve, for being the best, most loyal leadership team ever. Too many more to name without screwing it up and missing somebody important. I can’t say this enough --- THANK YOU for giving me the chance to be part of this great work.

I guess that’s it for now. If you need to get in touch --- look for me on Linked In.

Schmidt, OUT.

---S

PS. Family Health Guy will remain online but I won’t be adding to it any more --- seems weird to take it with me and weirder to hand it to somebody else.

It was a week well spent, though. In particular, HxRefactored 2014 was a great event; my keynote was fun (well, fun for me at least) and I got to attend a bunch of really great sessions that were super-relevant to the work we’re doing at HealthVault. Last year’s Refactored conference was great, but this year’s more explicit combination of design and development was even better.

Given the focus of the audience, I chose to spend my session talking about the challenges that real-world health data present for building great, simple user experiences and code that doesn’t blow up. Things that seem simple just aren’t, and if you build with a limited understanding of the domain, at best you’re going to end up with something kind of useless, and at worst you may actually hurt somebody.

Now, that doesn’t mean you should give up and just accept crap --- it just means you have to do your homework and recognize that if it really were easy, most health apps would be awesome already (they are not).

Health data is sucky in a number of ways:

• Measurements are often not precise and can vary significantly from reading to reading.
• For many types of data (e.g., diet), just capturing it in the first place is really cumbersome.
• Different systems are incredibly varied in how they represent equivalent concepts.
• Structured data is often unavailable, making automated computation really hard.

There are great strategies for handling all of these --- but it takes a very thoughtful designer to take the variability into account without allowing their interface to become a disaster --- and a foresightful developer to write code that doesn’t randomly get confused and throw exceptions.

Anyways, I’ve posted my slides here… but frankly without the voiceover I’m not sure how useful they’ll be. At least for those at the show that couldn’t read all that grotty XML from the back rows, now you have something to do on Saturday night. You’re welcome! Mobihealthnews also put up a pretty good article about the recurring conference theme of data challenges.

By far, my favorite session as an attendee was towards the end of the show, a combination of four shorter presentations under the umbrella of “Designing for Behavior Change.” We were introduced to:

• How avatars can immerse us in virtual worlds (except the fat Wii avatar was kind of a bummer).
• A neat mobile app to help folks get up and move during the workday (I need this).
• A tabletop board game to help folks talk about end of life issues (honestly, it seemed FUN).
• How the Kinect can be used to help folks recover through physical therapy (Martin, the dogo/mirror concept was really insightful and cool).

Anyways --- thanks as always to the Health 2.0 crew who do a great job with these events. Looking forward to next year!

What really caught my eye was the trailer for Edge of Tomorrow, an upcoming show where Tom Cruise has to re-live the same day of battle over and over again (kind of like Groundhog Day but with aliens and Emily Blunt). The tagline is LIVE-DIE-REPEAT, and suddenly sitting there I realized --- this captures exactly why I’m so lukewarm about FHIR! (Seriously, that happened.)

In case you’ve missed it, FHIR is the shiny new thing in health interoperability circles. A lightweight, modular, composable, built-for-REST set of content standards to describe healthcare stuff. It’s clean, and there’s a lot to like about it. Why, then, do I find it so uninteresting?

Because we’ve been here before. At least a few times. And it’s always the same story, because standards folks only have one tool in their toolbox: make standards. Here’s what happens:

1. The community defines a standard that is the state of the art for its time (HL7v2, IHE, Direct+CCDA, FHIR, etc.). People are excited!
    
2. But adoption at scale is hard --- and it’s mostly not because of technology. Sure, we have to get through vendor upgrade cycles and we run into unexpected code issues, but that’s easy. What’s really hard is fitting use of the standard into daily workflows, solving privacy and trust challenges, navigating politics, and most importantly demonstrating economic value.
    
3. Folks start slogging through the hard work. But it’s a long road, and takes time and persistence. People get disillusioned. Technical people get bored.
    
4. Sadly, the standards folks don’t have tools to deal with most of this. But they want to do *something* to make things better … so they look at that last standard/technology and see where it could be better. Go directly to step #1. FOREVER.

We never get to spend enough time on the adoption part to make it stick before somebody creates a new shiny thing and we all run after it. I really thought that Meaningful Use would change this … we got such great buy-in around Direct and the C/CDA, it’s being implemented, every day more and more patients are really getting their data, the BB+ Push pilots are working…. But it’s slow, and we’ve certainly run into challenges.

So, here comes the new standard to save the day. But even if this one is a little better technically --- and I’d wager it is --- that won’t matter. It’ll have its own set of scale adoption issues. What’s the service URL for each provider? How do you register each app with each provider’s OAuth endpoint? Are there policy requirements before somebody allows your app “in”? Anybody hear about something called Covert Redirection? What about push events; are we all going to be polling each other for new data all the time? And on, and on, and on.

The really sad thing is that I have to take some blame for this with Direct too. I thought we could break the cycle by including ideas like distributed “circles of trust” --- a system whereby once you’ve installed Direct, you can expand your trading partners over time without any technical changes. This is working, but not fast enough … the cycle of frustration with things like the Federal Bridge and arguments over identity proofing risk sending us right back to the starting line.

I don’t have an answer. And you know, if FHIR gains traction you can count on HealthVault to implement it --- our model fails without interoperability, so we have no choice but to play along. I just can’t force myself to get excited about the standards any more. As my good friend Umesh always says … old wine in new bottles.

All that said, the movie looks like a lot of fun.

Dum dee dum, waiting… ok.

Bill’s story has received a number of reactions and comments, but one in particular from Doug Dietzman deserves attention, because it highlights a common but critical misunderstanding --- one that makes all the difference to why a personal, patient-controlled “HIE” is so much more likely to succeed in the long term.

Before I go any further, I should say that I’m actually a supporter of “B2B” health information exchange too. HIE organizations are doing important work, especially making technology and services available to “white space” providers and to patients themselves. As I often say, I am thankful for anybody and everybody that is truly trying to help.

The full text of Doug’s comment is at the bottom of Bill’s blog, but in short, he challenges how a personal HIE like HealthVault can support the business transactions of healthcare --- such as getting lab results back to the ordering physician, or alerting stakeholders when new information is available.

These things are *exactly* what HealthVault is built to do.

I wrote about this in detail about a year ago in the context of patient matching and identification. What you have to understand is that HealthVault is not just some database in the sky. It’s a neutral, universally accessible “hub” through which information can flow automatically based on patient consent.

Here’s just one example of this kind of workflow:

1. Sean uses his family doctor’s patient portal to link his HealthVault record to the practice.
2. Sean visits a specialist and requests a copy of his visit summary be sent to his HealthVault Direct address.
3. The CCDA attached to that message is incorporated automatically into Sean’s HealthVault record.
4. The family doctor’s patient portal receives a notification via HealthVault’s “eventing” interface that new information for Sean is available. It pulls that down into the EHR inbox and next morning, the family doctor sees the information and is up to speed on the case.

Note that in this model, at least three historical “HIE” problems go away:

• The two practices don’t need any data sharing agreement at all. The patient’s consent with each practice “brokers” policy issues between independent entities.
• The two practices didn’t need an EMPI or any patient matching technology. The patient creates links using the patient portal in the first case, and exchange of the Direct address in the second.
• There is a built-in mechanism for efficient notification between systems.
• Provenance models already in place support information integrity.

And of course the benefits compound. If the patient has linked their HealthVault record to other practices, they get the data too. If they use consumer-focused applications, they update too. First responder systems like NOKR get the latest information. Coordinating care even between countries? No problem --- with none of the technologies having a clue about the others. It’s pretty awesome.

Now, of course, nothing does everything and there are certainly transactions better suited to direct business-to-business connectivity (hooray that Direct does both!) … but for the core HIE problem statement --- getting accurate, up-to-date information in front of the right folks at the right time --- it’s a slam dunk.

And the good news is, slowly but surely, it is happening.

It was a truly awesome experience. I did real work on real projects with real people. I wrote my first Windows apps, learned how to debug, and developed an addiction to code that has been one of the best parts of my life. The addiction to Diet Coke was a less lucrative, but equally permanent, side effect.

Suffice to say I have a deep love for the college internship program at Microsoft.

A few months ago I got a note from one of our recruiters about a college kid named Karl who was interested in healthcare technology and looking for a winter term internship. He’d already done one stint at the company and gotten high marks, so after a quick call we committed to bring him on.

Of course, we then kind of forgot about it until a couple of weeks before he showed up. ;) But when he did, he got busy pretty dang quick. One of the top HealthVault requests we’ve had for a long time has been to import measurements from spreadsheets. It was a nice, isolated but very real problem. The result? Check this out:

Honestly, I expected that maybe Karl would finish some limited, basic code that we could use as a starting point for the “real” feature. Nope. You can expect to see spreadsheet import show up very soon in an official HealthVault release. Well developed, integrated into our production site, and ready to go. The feature as written:

• Works for a number of common tracking types,
• Adapts to pretty much arbitrary column structures,
• Manages unit conversion,
• Presents a handy preview to help manage the import, and
• Even passes our huge battery of security and geopolitical compliance tests.

Wicked stuff.

He also is a pretty crappy hallway golfer, which I value because it lowered the bar I have to hit to qualify as “acceptably mediocre” in our weekly tournament.

So is he coming back? You bet, if we have anything to do with it. Too cool. 

Today’s awesome is from the folks at California Direct, powered by the team at Axesson.

First of all --- ANY provider can sign up online to get a California Direct address. They can use the address “standalone” using the very capable Mirth Mail web interface, or connect it up to their EHR if their vendor supports that.

The really sweet thing here is that, thanks to funding from California Health eQuality … the first 1,000 accounts given to providers in rural California are completely FREE. So for a huge number of California providers, there is now no cost whatsoever to use Direct. Get ready to dump that fax machine, baby!

OK, but what about the patients? No problem --- California Direct is already set up to exchange with HealthVault and other PHRs. Meaningful use support? Yes indeed. If you are a California patient and want a copy of your data in HealthVault, ask your doc to send it to you using California Direct. And don’t take “no” for an answer … print out a copy of this info sheet and write “californiadirect.org” at the top!

But wait, there’s more.

As a patient, you can send information TO your provider as well --- including data that could be useful to your visit. Say you’re tracking your blood pressure and have a follow-up with your doctor to see if that new exercise and diet program is doing the trick. Wouldn’t it be nice if she could see that information in her EHR? Well check this out:

On the left is the interface in HealthVault to attach your health information to an outgoing message. You pick the types you want, a date range if desired, and we automatically create the attachments you see on the right side:

• A machine-readable, structured C/CDA file that can be automatically imported into most EHRs,
• A human-readable and printable HTML version of the same information, and
• A request.txt file that gives the recipient information on the source/provenance of the data.

THIS IS A MOONSHOT, PEOPLE.

As a patient you can use any HealthVault-connected device, one of our mobile apps or just the web --- you choose how to track. And any provider with a California Direct address can receive that information ready for import into their EHR. Seriously. This is really doable, today.

So……… start doing it!

The National Association for Trusted Exchange (NATE) has been a big part of that progress --- NATE’s  pilot programs, sponsored in part by the ONC,  did a great job teasing out remaining real-world issues, and it’s been great to work with the team there, in particular CEO Aaron Seib.

An IMpatient guy (you reading this, Jeff?), Aaron is now pushing hard to enable the next obvious workflow --- patients sending information to their providers. Think visit summaries from past encounters, home monitoring data, and so on. And he’s not alone; “patient-generated data” (or perhaps more accurately patient-supplied data) is quickly moving up the industry priority list.

A key issue that always comes up in that discussion is “provenance” --- if data is provided by a patient, how can the receiving provider make a judgment as to its veracity? Concerns arise not just around explicit fraud (e.g., drug-seeking behavior), but also perfectly honest “telephone game” mistakes --- e.g., did the specialist really conclude you have a particular condition, or was it simply a possibility?

Direct is a great mechanism for sending data from patients to providers … but it doesn’t have a mechanism to express the “provenance” of data shared in that way. And while the C/CDA is an excellent way to package information for exchange, it doesn’t really help with that either.

At a recent NATE workshop, Aaron and others proposed an extension to the Blue Button + “request.txt” file that would carry provenance metadata in a simple form that providers could review. We thought it was a good idea, so as of now, HealthVault always adds this metadata when sending attachments via Direct. A few examples:

• Document-Source:name="Visit Summary.xml";source=<drbob@direct.myclinic.com>"
• Document-Source:name="Glucose Readings.csv";source="PATIENT"
• Document-Source:name="HealthVault Record Data (CCD).xml";source="MIXED"

In the first case the attachment was forwarded from a known Direct address. The second was information uploaded by the patient themselves. The last is a composite file created from a number of sources. It ain’t perfect, but it’s a nice way to start the process --- simple and easy.

Enough from me --- Aaron has thoughtfully agreed to write a few words about why he thinks provenance is a key piece of the puzzle, and how he hopes to get other folks excited about this new metadata approach:

First, I really can’t take any credit for the incredible results that NATE has had so far piloting these concepts.  We have been really fortunate to get support from our member states, the VA and the University of California San Deigo, HIOs in CA (San Deigo Health Connect and Axession), OR (CareAccord) and AK (Alaska eHealth Network) as well as three amazingly collaborative PHR vendors – NoMoreClipboard, Humetrix and of course, Microsoft HealthVault. 

I think the real reason we have been able to make such great progress together is that there is a resounding demand from everyone’s stakeholders to make it practical for patients and providers to be able to benefit from the use of Directed Exchange to improve outcomes, patient satisfaction and provider workflows.  NATE’s part so far has been mostly facilitative and specific to enabling bidirectional trust between the systems being employed by consumers and those being employed by providers.

We all agreed to start as simple as possible and only address the biggest barriers to getting to square one with regards to bidirectional interoperability between patient’s and providers.  On the consumer side it came down to figuring out how to make the workflow for the patient as secure as necessary without setting the bar so high that only the most motivated users would bother getting started.  Recognizing that the greatest ROI isn’t going to be realized by working with only those consumers that are already motivated and engaged in their care.  At the same time we all understood that providers (and to a higher degree still the states and other entities that have to satisfy a higher bar than most private entities like the VA and other payers) were concerned that they didn’t have enough information to be comfortable disclosing to just any end-point.  So the first thing NATE did with the pilot participants was establish a process to help ease the burden and provide a way to enable Direct based exchange between PHRs and Providers – that is to say we created a Pilot Trust Bundle and working with the participants established the onboarding criteria for PHRs to be added.

This step helped get real world use yet it wasn’t the entire equation.  It isn’t just about making PHRs consumer friendly and helping differentiate those that comply with baseline security and trust requirements more easy to recognize - it’s also about making it work in the provider’s workflows.  We recognized, thanks to the participation of practicing providers and practice management personnel who helped us early on in the pilot, that the current state of the art when data flows from the patient to the provider didn’t really match the work flow of the provider’s practice. 

Practices have always received information from all types of sources.  All practices have had paper based data receipt procedures that they follow based on the type and source of information that they are receiving.  What is missing in the electronic receipt process is a computable method of following those procedures.  The functionality represented by the request.txt capability that Sean is announcing can go a long way toward helping practices better handle incoming data from consumers.

So far NATE has made some remarkable strides but we recognize that we are just getting started.  There is much to learn and many more folks for us to learn from.  We are nearing the completion of the pilot work that we have been doing in relation to the ONC funding activities and a report will be published soon highlighting the lessons learned from the pilot and our recommendations for next steps.

Included in the report’s recommendations is the need to “continue to collaborate in the next phase of this NATE initiative ~ by making a broad call for participation of more ~ PHR vendors and EHR vendors as well as others working in this domain to inform future work”.  We hope to continue to work with everyone who has been involved so far, including the ONC, and will be making a broader call to interested parties but it would be great to hear from those of you who are interested in being part of the next step in this movement.

We know we don’t have all the answers and that we need a lot of help so if you’re interested in staying informed about next steps please let me know via email at aaron.seib@nate-trust.org !

Comments on Voluntary 2015 Edition Electronic Health Record (EHR) Certification Criteria (RIN 0991-AB92), Content & Transport revisions.

I am writing to share concerns about proposed Content and Transport / Direct Messaging rule revisions in the 2015 NPRM. I appreciate the opportunity to comment, and would be happy to respond to any requests for clarification or further detail on these issues. As a core member of the founding group that created the Direct Secure Messaging standard, I hope I can offer a useful and relevant perspective.

The 2014 rule contains two measures that rely on Direct messaging --- exchanging care summaries in C/CDA format between providers, and sharing the same from providers to patients. The tests for these measures are relatively simple --- NIST has a Direct system for testing, and the candidate EHR must be able to exchange valid messages with it.

In the new proposed rule, ONC responded to community requests to “separate content from transport.” Because the C/CDA format and Direct might evolve independently, tying them together reduces flexibility. This makes total sense … we’ve had that issue bite us in HIT standards before, back when we tied everything to SOAP and WS* (Microsoft has to take some blame for that one along with everyone else).

The problem is --- the rule changes don’t do that at all. They just change what transport is tied to the content. And worse, this new “transport” is under-specified to such a degree that there is no way to guarantee interoperability with it. It’s frankly a big mess.

To explain, let me back up a bit. When we were first designing Direct, we theorized that it might be useful if an organization could “outsource” message transport to a third party, in exactly the same way that many organizations do for regular email. We called these organizations “HISPs,” and we architected the technology so that the message transport could be easily (but optionally) decoupled from a “client” EHR system that wanted to send and receive messages:

We very explicitly chose not to specify the “edge” transport, because we envisioned tons of different EHR/HISP configurations useful in different situations --- and we were right. Systems like Epic were able to accelerate their development by leveraging existing XDR capability; HealthVault uses file drops because that’s convenient for us; others just use SMTP over a trusted channel; Relay/McKesson uses a custom lightweight SOAP approach, Cerner does something I have no idea what it is, and so on. The point is --- it doesn’t matter, because what is important is that we all use the same “backbone” transport of Direct to achieve interoperability.

The 2015 proposals change this approach by explicitly defining a finite set of certified edge transports as detailed in a new work product, the “Implementation Guide for Direct Edge Protocols.” EHRs would be required to use one of these edge transports to send a valid C/CDA to a HISP, which then presumably will send it off using Direct.

Which finally brings us to the three key problems:

1. The new rule doesn’t separate content from transport at all. It just replaces “Direct” with “XDR, SMTP, IMAP4 or POP3”. They’re all transports. If we really want to separate content (and that’s a fine idea), we need to do it correctly and create tests that validate C/CDAs in full isolation.
    
2. The edge systems in the proposed IG are dramatically underspecified. Just as one example, the guidance for SMTP as an edge transport says in effect “comply with RFCs 2821 and 2487.” Neither of these RFCs say anything about how the channel should be authenticated, which means there is a good chance that any given EHR and HISP will not be able to work together.
    
3. The new rule limits flexibility in the very place we need it. As described above, there is great variability in the edge transports that different systems have chosen to use … with good reason, because there is great variability in the EHR systems themselves. And there is a natural market between EHRs and HISPs that eliminates any need for mandates. For example, given Epic’s market presence, every credible HISP will happily implement whatever edge transport they choose.

It is fair to say that, in cases where an EHR has chosen to rely on an external HISP, it is a bit awkward to certify under the 2014 regime. But it clearly has worked --- and because it is a functional test that requires a complete end-to-end test with the NIST system, we have seen an exceptionally high degree of interoperability emerge in the real world. Breaking apart this end-to-end chain by only testing EHRs against (incompletely defined) “edge transports” will surely result in less, not more, success.

In short, the referenced Direct Edge Systems IG should not be part of any rulemaking at this time.

We’ve got a good thing going with Direct. The technology works, it’s being implemented widely, and the trust fabric is growing more complete every day. Please, let’s not mess it up now … we’re so close.