CMIO magazine just published an extensive article on the use of PHRs and patient portals. Yours truly had the pleasure of being interviewed for the article (while I was still with Children’s Hospital Boston) and they ended up using quite a bit of our conversation in the final piece – so much so that I had to make sure they actually credited the people who actually rolled out CHB’s PHR!

At Beacon 16 we’re still very focused on portals for both patients and providers. Beyond formative work on the Indivo Personally Controlled Health Record and the Dossia PHR platform, we’ve also built portals for providers, allowing community physicians easy and intuitive access to the parts of hospital records that are most important to the referring physicians in the community.

These days, we’re doing more mobile design at Beacon 16, and our usual suite of design shapes, stencils, and templates weren’t cutting it.

Despite regular aspersions cast from the rest of the design community, I still like to use Visio for my early wireframes and mockups — Visio is fast, interactively accurate, and accessible to the non-designers with whom I collaborate. (Visio 2010 is especially slick.)

Absent a great Visio iPhone stencil to download, I’ve decided to create one.

(more…)

If I said that my research objective was “to assess the patient-centeredness of personal health records,” who would you recommend that I interview?

I was flipping through a recent issue of JAMIA and noticed this article, “Improving personal health records for patient-centered care.” Some informatics folks at a nearby hospital took on the above objective, but used a curious strategy — they interviewed seven senior executives, three from hospitals, two from insurers, one from a commercial vendor, and one from a government agency.

For us, that would make a good project kickoff — get the perspectives of key decisions-makers first. Then, we’d go straight to the only people qualified to say whether a piece of software works for patients: patients themselves.

Google announced a few days ago that they were killing Google Wave. Wave was a product that very few people used, despite it having been launched in a pretty high profile way. The technology community spent weeks talking about it, and Google pitched it as the “email killer.” I played with it shortly after the release and didn’t get it – the examples all focused on planning barbecues and it wasn’t clear how this tool was supposed to integrate with my day to day workflow.

A little over a year later, I’m really quite upset that they’re taking my Wave away. Because about six months ago (after they’d improved the technology a bit) I figured out what it was good for. Wave didn’t replace all email. It replaced entire chains of email. And in a software development organization like ours, that’s a very useful thing to be able to do. Most organizations have tremendous knowledge locked up in email. Someone asks a question, someone replies, someone else replies to that. In the end, a strategy is formed – but nobody wrote up a summary and anyone coming into the project later is out of luck. And in an inbox of thousands of messages, it’s pretty easy to miss one.

With Wave that changed. To take a concrete example, we’ve done a lot of work recently that involved integrating Cerner’s Millennium platform, particularly the PowerChart Electronic Health Record. That’s a challenge, and we had to build a lot of internal knowledge about how the system worked – both in general and about specific implementations. Cerner has some documentation, but we had to do a lot of experiments and talk to a lot of people. Encounter data proved particularly tricky. So we started a Wave – the first version of which was, essentially, “we need encounter data for these three things.” And then people commented and asked questions, and added content, and revised it, and in the end we’d had the same conversation that we would have had over email (or, even worse from an information capture standpoint, in a conference room) summarized into a very neat document that answered any question that anyone might have, and laid out our implementation pathway as well. We did the same thing for a number of other issues. In the end we had about fifteen Waves for that project, dealing with everything from design decisions to installation instructions to lists of sample data. They probably replaced a couple of thousand emails, and made documentation at the end of the project extremely easy. And because each conversation was separate, we could invite customers and collaborators to take part in particular Waves, rather than having to give them full access to a wiki (which was generally more work than people wanted to do, anyway).

So I’ll miss Wave. We’ve used lots of other tools to try and solve the same problem, including Google docs, wikis, and custom software, but Wave did the best job. The key was the messaging metaphor – once you started thinking of it as way of managing conversations, using the Wave to collaborate became quite natural. There were still some missing features (mobile access was hard, as was printing and exporting, since Wave allowed embedding of files, Google Gadgets and other hard-to-print artifacts), but the software was getting quite good. Google just promoted it to the wrong audience. It’s not a general use tool, it’s a corporate and small business tool.

Hopefully the best parts of Wave will turn up in other products. Until they do, we’ll go back to project wikis for collaboration.

We just finished up a very big project with one of the major Boston hospitals. It was a great project – lots of strategic implications for the client, some interesting technology, and a user community eager for someone to solve the problem we were trying to solve. Of course, it was also one of those zero-to-sixty in three seconds kinds of projects with tendrils into EHRs and hospital information systems. We started with a blank piece of paper in January and at the end of July handed our work off to the internal IT department. They’ll be putting it into production this month.

We’ll be posting a case study on the project itself soon. But right now I want to talk about something we observed during the design process. Ideally, we like to get in on a project as early as possible so we can be involved in talking to users, validating assumptions about requirements, and making sure the customer is actually going to get what they want. It also helps us make sure that we don’t get stuck in a situation where the project may fail. This may not seem to be in our best interest from a business development perspective, like the time we did a round of user research only to discover that if the project went ahead nobody would use it (we still felt like we gave the client the kind of service they needed).

This time we got to do the whole cycle. We started with about thirty hours of interviews with primary care physicians throughout Massachusetts. Some worked in big hospitals, some worked in solo offices, some were in the middle. We asked them about their referral patterns to different hospitals, about the kinds of information they need to make decisions, and where their frustrations were when dealing with hospitalized patients. We had them talk through the process of caring for a sick patient, and learned a lot about what was working for them and what wasn’t.

After the initial interviews we came back around to share mock-ups and designs with a selected subset of our initial interviewees. They loved it, and their feedback was useful and easy to incorporate because we were still at the design stage. Once development was well underway, we went back a third time. This time we had working software to show them. Or, at least, more or less working software. Normally IT groups tend to shy away from showing partially finished software outside of very controlled environments. We’re careful about that ourselves – a bad first impression from a key user can really hurt a project during the broad roll-out, even if the bad impression was of early stage software six months before launch. But in this case we felt good about it since the users we were talking to had already been exposed to the design process – they knew we were still working towards the end goal, and they had a lot of fun seeing how their suggestions had (or hadn’t) been incorporated. Nobody got upset if a particular suggestion hadn’t been taken, and a few of them were very helpful in characterizing issues that we hadn’t been able to identify back in the office.

Subsequently, I’ve heard that these design partners have been aggressive proponents of the new system within their respective organizations. When it rolls out, they’ll be the first ambassadors – not because someone tells them to, but because they were involved in the creation and rightfully see the end result as the result of their work as well as ours.

And that’s how your users become champions of your product.

I’m at a conference at Harvard Medical School today, with various industry and policy luminaries. Federal CTO Aneesh Chopra and HHS CTO Todd Park were just speaking. Reginza Herzlinger is giving a talk right now. Clayton Christensen was here this morning. Gotta love Harvard, and I’ve got a number of thoughts which I’ll wrap into a set of posts over the next few days.

But until then, I wanted to draw out a single point that has recurred a lot in various conversations I’ve had over the last few days. Christensen brought it up again in his keynote this morning. It’s this: the best care for complex disease is delivered by groups of physicians who are coordinated with each other. That coordination comes from being in the same room.

Dr. Christensen’s example (from his book) is an acquaintance spent years looking for appropriate treatment for his asthma. Over several years he saw many different specialists, and they didn’t solve the problem. Then he saw the same set of specialists (different people, same expertise), all in the same room, after flying to Denver. And they figured it out in 30 minutes.

I saw something similar this winter after visiting a microvascular disease clinic at Massachusetts General Hospital. It was a volunteer effort, run on a Saturday morning, with 6 or 7 experience specialists and a few residents and fellows. They saw patient after patient, all of whom had been bouncing through the system – and more or less without exception, they knocked each problem down as fast as it came up.

So here’s a question for healthcare reformers and healthcare technology innovators. How can we create that same quality of care for everyone who has a difficult to diagnose condition?

I’m sure at least a few people have been wondering where we’ve been the last few weeks. We’ve been busy on a number of products, and we released one of them at the end of June. It’s called Clickframes, and it’s a set of frameworks for building usable, reliable, scalable software faster, better and cheaper. The original Clickframes concept was based on three observations:

• Good software requirements can be very useful.
• Most software requirements aren’t very good.
• Even when requirements are well thought out, they’re generally created in a format that limits their usefulness.

At ISG, we develop software using a design methodology that focuses on understanding user needs through interviews, observations and deep research. We learn as much about the problem space up-front, do as much work as possible to validate our designs with real users, and only then proceed with the implementation. This approach works very well for us (and the one time we allowed ourselves to be persuaded to approach a problem differently the results were a lot more typical for the industry), but it requires a lot of agility. Clickframes helps give us that agility by turning static software requirements into a dynamic specification of how the application should work.

Here’s how it works: at some point during the design process we start building an application specification (or “appspec”), which is a description of the web application we want to build. The early iterations can be very schematic – identifying a couple of pages, perhaps a form or two, and a few buttons. As we learn more about the application we can extend the appspec to include additional detail, including specific requirements, security, and flows between different pages in the application.

That’s actually all pretty standard, so here’s where things get a little different. The appspec isn’t a Microsoft Word document, or a stack of index cards, or a drawing on a wall. It’s an XML file, and it’s maintained by the application’s lead designer. By managing requirements in XML, we can generate a whole range of useful artifacts on the fly. The most important is the Clickframes Interactive Preview (click the link for a sample from our Issue Tracker demo), which provides an easy to navigate HTML representation of the application. As requirements change the CLIPs can be easily regenerated. Clickframes also provides generators for conventional requirements documents (the system shall…) and a visualization tool that generates interaction maps of the application. Here’s the Issue Tracker example, generated from the same appspec as the CLIPs linked to above:

Once the design stabilizes, we move on to implementing the software itself. Clickframes helps here too. We’ve built code generators for three different web architectures – PHP, JBoss Seam, and Spring WebFlow (the latter two, for the non-technical reader who has stuck it out this far, are Enterprise Java platforms, and the first is a very common scripting language for web applications). This is an area where conventional prototyping tools break down – they don’t provide a bridge to development. With Clickframes, the plugins give us a skeleton of the application immediately, and our developers and designers can go in and immediately start creating content and the final look and feel, rather than worrying about details like implementing edit checks on form fields. If you want to see the Clickframes Issue Tracker demo, just click on the link (to log in, enter anything for the username and password). This isn’t a complete application, by the way – it’s just the generated code, before being customized by a programmer.

We’ve spent a lot of time on the Clickframes code generators and on the architecture of the underlying applications. We’ve implemented a range of features we call “CodeSync” that allow us to regenerate applications even after the development team has started to customize them. This is critically important, because it keeps the requirements from becoming out of date. If a business user, or a a designer, wants a change made, they can have the appspec updated and the programmer can re-run the code generator. It creates a feedback loop that’s often missing.

The final step in the Clickframes project lifecyle is testing. Since we have a version of the software requirements that a computer can understand, we can use it to generate a suite of automated tests, as well as templates for test strategies and manual test scripts. It’s not magic – the quality assurance team still has to do some work, and we can’t automatically generate every single test, but we can save a tremendous amount of up-front work. And developers can have access to automated tests of the final application almost from the first day of development. It saves a tremendous amount of time.

Clickframes is software to streamline development of enterprise applications. So how much would you pay? Don’t answer, because it’s free – we’re releasing Clickframes as Open Source Software under the LGPL. You can download Preview Release 1, sign up for the mailing lists, and see some demo screencasts at www.clickframes.org, and you can find a lot of documentation on The Clickframes Wiki, including instructions on how to get started without downloading anything. The Preview Release is out there to gather feedback – we’ll be releasing new versions at a pretty rapid clip over the next two months, with a goal of 1.0 by the end of the summer. We’re also rolling out some new web site features in July that will make it easier to explore the Clickframes model.

This has been a long road for all of us – we started working on Clickframes back in May of 2008, so it’s been over a year to get to this point. So give it a try and let us know what you think!

(And if you like it, or like what we build, give us a call – we’re always looking for interesting new projects).

The Federal Trade Commission has issued a draft rule that outlines how PHR providers must notify consumers in the event of security breaches (warning, PDF!). The rule includes platforms like HealthVault and Google Health along with individual PHR vendors like WebMD and ActiveHealth. Comments can be submitted here, and are due by June 1st. This does NOT affect HIPAA covered entities such as hospitals and insurance companies, although the Department of Health and Human Services will be issuing one soon, and the content is expected to be quite similar.

The Recovery Act contained temporary requirements, which will remain in effect until Congress passes new legislation based on a report currently in development by HHS and the FTC. The report is due in a year, and legislation takes a long time, so these “interim” requirements will almost certainly be in force until 2010, and possibly longer. Interim rules that hang around long enough tend to be the basis of permanent rules.

Here’s a summary of who is affected and under what circumstances:

• A “breach of security” is defined as the acquisition of identifiable health information of an individual, from a PHR, without authorization.
• The rule also contains the word “unsecured.” This means encryption – if a laptop containing appropriately encrypted data is stolen, that doesn’t count as a breach for notification purposes. HHS is responsible for issuing a guidance on acceptable security policies, to be updated annually.
• Access is not the same as acquisition. Employees looking up records about friends and celebrities is a breach. An employee inadvertently loading the wrong record in the EHR is not.
• The “fact of having an account with a vendor of personal health records” is itself considered sensitive information. The obvious example (used in the notice) would be releasing a list of names by a company that provides PHR services for AIDS patients.
• De-identified information, according to the existing HIPAA de-identification rules, fall outside the scope of the rule.
• “PHR related entities” are what the platform vendors call “Personal Health Applications”. It’s a broad net, and the examples include websites offering medication management applications and bricks-and-mortar companies advertising dietary supplements online, as long as the interaction with these companies is through a PHR or PHR platform. The definition also includes organizations that “access information in a personal health record or send information to a personal health record.”

The breach notification requirement itself has a few components:

• Third party service providers must notify their customers (vendors of PHRs and PHAs) following the discovery of a breach. The individuals affected must be explicitly identified.
• Notice must be received by a “senior official” of the PHR vendor or PHR related entity.
• There is a “reasonably should have known” clause that sets an expectation of reasonable security measures. You can be in violation of the rule if you didn’t detect the breach in time. But since some breaches are hard to detect, you’re not always in violation if you discover something belatedly.
• Notifications to individuals must be made “without unreasonable delay” and always within 60 days.
• Notice must be by first-class mail, or by email if the individual consents (which must be “affirmative” consent, not something buried in an end user license agreement). There is no obligation to provide notification by mail (although if the customer doesn’t consent to email notifications, you can’t provide them with service otherwise).
• If ten or more individuals can’t be reached, a substitute notice must be posted – a large link on the home page for six months, or through a media campaign.
• The FTC must be notified in five business days if 500 or more people are involved. If fewer than 500 people are involved, reports may be submitted annually.

That’s not all there is to it – the rule also describes the content of breach notices and the supporting document includes an economic impact assessment. I wrote some similar impact analysis documents when I was at CMS – it’s always a challenge to get it right.

My quick reaction: it’s not bad. We’ll see every PHR vendor race to add that “email notification” permission to their products. The cost of compliance shouldn’t be that burdensome, although it’s certainly non-zero, and that’s really the point – organizations need to take security seriously, and making breaches costly and embarrassing is a good way to do that.

Steve Portigal at Core77 mentions last Monday’s article in the New York Times about a new study from Israel that shows radiologists write more thorough reports when a file includes the patient’s photograph. Sequestered in dark rooms, surrounded by computers, radiologists rarely meet their patients — being able to see even a glimpse of humanity among x-rays, CT scans, and MRIs seems to create a beneficial connection between doctor and patient that otherwise wouldn’t exist.

This new study opens up additional areas of research: do photographs improve distance medicine? What about surgical procedures when the patient’s face is blocked by a curtain? Or online pharmacies that never meet face-to-face with their customers?

Can PCHRs provide the data to personalize a medical encounter?

Back in 2006, when we redesigned the personal health data model for Indivo 3, I successfully lobbied to include a photo element in the patient’s contact information document. At the time, I just thought it was logical to have a picture of the patient in the patient’s record. Unfortunately, other development tasks took priority over integrating the photo feature into the reference UI. The idea languished until I did some designing exercises for a next-generation PCHR user interface several months ago. My approach was to learn from the success of social networking systems to make a PCHR interface more human-centered and engaging. In our earlier work, we had been thinking so much about making PCHRs secure — it was fun to think solely about making them usable.

Including a photo in a PCHR patient profile

A list of family members with identifying photos

Now here’s where things could get interesting. Our interaction design process relies heavily on personas — composite visualizations of key users built with the ethnographic data we collect in our field research (interviews, surveys, etc.). It helps our team rally around our users as we design and build software. Every design decision gets filtered through our personas. “How would David build his research team? Does he think about roles, or does he already have collaborators in mind?”

An example of a persona from our grant collaboration project

Could a medical “persona” have the same impact in the delivery of healthcare? Patient summaries as they exist today (and to the extent I’ve seen them) stick to core data like procedures, problems, lab tests, and immunizations. Primary care physicians, who we expect to develop a fuller, more human view of their patients, have increasingly less time to devote to social interaction. In our design personas we include sections for motivations, behaviors, and obstacles — might such information help caregivers move beyond the minutia of clinical “tasks” to, dare I say, “goal-directed” medicine?

A quick followup to yesterday’s post on PHRs and Claims Data. Sean Nolan, the architect of HealthVault, has a nice comment on John Moore’s post on the Boston Globe article that does a nice job of explaining their “package and reconcile” model for importing data into HealthVault. For those wondering how PHR platforms map to document standards like the Continuity of Care Record, this is a nice clean explanation.

Bad Data & PHR Adoption « Chilmark Research.