After a recent visit to my doctor, I received a notice that my health information was available to view in my online portal. So, inspired by ongoing exposure to public/private tag-team HIT evangelism, I decided to don my patient cap and download “my damn data”, brush the dust off of my HealthVault account and update it with some fresh info about myself. Or so I thought.
Like many of his peers around the country, my doctor happens to be a good guy who uses bad software. The patient portal I’m subjected to is a HealthFusion product called YourHealthFile. Barebones but functional, it was very likely designed from start to finish with Meaningful Use paychecks in mind. I logged into the PHR, opened up my HealthVault account in a second tab, and tried to figure out what to do next. After opening up a help site (third tab), I figured out that I can import automatically if my PHR is a listed HealthVault App/Device partner, or manually if not.
I didn’t see any HealthFusion products in the list, so I ran a Google search (fourth tab) for “HealthFusion and HealthVault.” Nothing – save for an unintentionally ironic corporate blog post about the need for interoperability between systems like HealthFusion and HealthVault, from two years ago.
Next I navigated back to my PHR and clicked around until I found the “Download my PHR” button, which launched a download window (fifth tab). I excitedly opened up the folder and saw three files, ending in .xsl, .xml, and .pdf. I tried to upload the CCDA (xml file) and got this lovely message (text verbatim):
“We couldn’t complete your last action because: There is a problem with the way the file is constructed. Please ask the provider to correct it and give you a new copy. The following information may be useful to your provider in identifying the problem: Invalid xml for thing of type ‘9c48a2b8-952c-4f5a-935d-f3292326bf54 (Continuity of Care Document (CCD)). The ‘code’ attribute is invalid –The value “is invalid according to its datatype ‘urn:hl7-org:v3:cs’ –The Pattern constraint failed. The ‘code’ attribute is invalid –The value “is invalid according to its datatype ‘urn:hl7-org:v3:cs’ –The Pattern constraint failed.”
Indeed. I didn’t agree with the assessment that my provider would find it useful, as I’m pretty sure he has a flip phone and his front office staff is three middle-aged women who frame their desktop monitors with post-it notes. After finding that I couldn’t upload the .xsl file either, I warped back to 2004 and made do with a .pdf file.
While it is disappointing to be personally involved with such an error, it is no surprise or secret that this sort of thing happens with regular frequency. Sean Nolan from HealthVault was helpful enough to respond to a tweet and reach out to the HealthFusion team, where he found the error was based on a blank field under an optional portion of the paper form I had filled out on a clipboard during my first office visit. Such issues – glaring syntax errors, improperly tested files, poor file integrity analysis, so on and so forth, are part and parcel of working with data. But how these glitches are handled – by vendors, by the delivery system, and by patients – points to a deeper challenge we face in patient engagement.
As a relatively healthy patient, I didn’t have much to lose (or seemingly gain) from what should have been a routine CCDA upload. But if interoperability through standards-driven data exchange is being billed as the latest, greatest way to improve patient safety and health outcomes, then…who’s making sure that it works?
ONC certification is important but limited to a handful of test cases per vendor; in the case of HealthFusion, this was obviously ineffectual. To be sure, the progress the HIT industry has made with interoperability in the last few years, even just moving from MU1 to MU2, has been substantial. We now face the challenge of organizational workflow, which raises several questions that go beyond whether we can get data from point A to point B.
In an era of “accountability,” who is keeping patients from falling through the cracks? Are expectations for patient responsibility being set by doctors, technologists, policymakers, patients themselves, or somebody else? In my case, neither my doctor and his staff, nor the faceless portal technicians were able to help. I had to go through a third party vendor and rely on a personal relationship to figure out what was going on.
I’d hardly call that patient empowerment – how about patient frustration or worse, patient resignation from ever going through this convoluted process again. I’m positive this is not the objective of DC policy makers, but it is current reality.
Another speedbump, from beyond my tiny doctor’s office: My health insurer’s behemoth parent company, HCSC, proudly displays the Blue Button pledge on their homepage, even though I can’t actually remove any of my own claims information or any other data off of my BCBS TX member portal. Lipstick on a pig comes to mind.
Our industry typifies society’s broader tendency to move towards the next big thing when it comes to technology (quite literally by Samsung). New data transport standards, new policy programs and product upgrades, new features and capabilities. Innovation is certainly needed in healthcare, but not at the cost of progress.
As much as I track and analyze the budding patient engagement industry, I have yet to see anything beyond minimally working versions of it in my own experience – and I am certainly not alone. As expectations and stakes go up, younger people hit the rolls, and Meaningful Use slows down, patient engagement will need to move from technology and policy to organizational culture. Perhaps John is right and market forces will pick up the slack. In the meantime, this Kool-Aid is starting to taste like water.